tesnexus8 Posted March 8, 2022 Share Posted March 8, 2022 (edited) 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 March 8, 2022 by tesnexus8 Link to comment Share on other sites More sharing options...
Solution Tannin42 Posted March 9, 2022 Solution Share Posted March 9, 2022 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 More sharing options...
tesnexus8 Posted March 17, 2022 Author Share Posted March 17, 2022 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now