Jump to content

BUG: Lots of debris left behind after uninstalling Vigilant


tesnexus8
Go to solution Solved by Tannin42,

Recommended Posts

I removed Vigilant SE and two other associated mods (English translation and English VA), and out of curiosity looked for *vigil* still in Data/. It turns out there were a LOT of hits, all in two trees: Data\Sound\Voice\Vigilant.esm\*, and "Data\Sound\Voice\Vigilant Voiced.esp\*".

 

Both trees have a __folder_managed_by_vortex file in them (as well as all the subdirs), and all the mods were installed and removed via Vortex without any manual changes along the way, and also with the "Delete Archive" box checked, if that matters.

 

There are correctly no files IN any of those dirs, other than the "__folder_managed_by_vortex" one, but the trees themselves should have been cleaned up too, and haven't been.

 

It's not a huge problem, but I see that several other mods I've removed over time have also left traces behind that shouldn't be there, and it does start to add up after a while.

Edited by tesnexus8
Link to comment
Share on other sites

  • Solution

That is intended behavior, the __folder_managed_by_vortex don't having to clean them up would require deployment to look for empty directories, making it slower.

The directories will disappear if you purge and then deploy again.

 

Alternatively you can enable "Clean up empty directories during deployment" in Settings->Workarounds but it is a waste of time every time you deploy.

Link to comment
Share on other sites

  • 2 weeks later...

Thanks.

 

I can live with it: as you say, the workaround has a downside that outweighs the benefits.

 

I think that tying the fix to *deployment* is the wrong approach (in the abstract, I mean: it's your code, and that may be the only sane place TO do it for other reasons, which I wouldn't know) - removing a mod is a specific action, so queuing the purge task would only happen then (and distinctly so, rather than EACH deployment scouring the entire game tree every time it runs "just in case", which as you say would suck). Assuming you have any sort of queue priority management in there it wouldn't run until the deployment queue was drained (and would then block further deplyoment in return until it completed).

If you don't have the right architecture to handle that already though, then yeah: not worth it just for this, as it would be begging to race.

 

Purge is the right answer, I agree, so if we can't have it automatically then doing it by hand is fine - and will be literally effortless for me, because I'll never remember to anyway. :)

 

gl

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...