Vortex after a drive restore (every mod needs apply and hangs after 3-4 clicks of apply)

[lokiX1]

I will generally say I am liking Vortex. I like the quickness of profiles (I create many merge mods packs for myself and easy switch out of profiles is nice). However, I have run into one issue I have yet to figure out how to get around.

 

I recently lost my boot drive. But being an OCD IT consultant (read Anal Nerd), I backup my files to multiple locations. Unfortunately when I restore '/Users/Myuser/AppData/Roaming/Vortex' it appears to think that all my mods files changed (since I just restored the profiles). The problem is not necessarily that, it is that I either have to say Apply or Undo on 300+ lines of mods. Again not the core issue, The real issue is that if I attempt to use Apply, I get about 3-4 items down my list and then Vortex appears to hang. If I let it go it never finishes. I let this run for over 15 hours at one point (I was distracted working and happy to see if it ever finished) and it did not ever allow me to click apply on item 5. In addition I looked and Vortex was utilizing 57GB of my 64GB of memory.

 

So My questions are these? 1. Is there really a proper way to restore what I should have for Vortex after a drive failure? (Detail is that Vortex stores the mod dirs on another drive, however the profiles I am thinking are in APPDATA on C: as they did not show up until I pulled that back over). 2. If this is simply a memory leak, is there a way I can verify the permissions or checksum and (if permissions are used) I could then write a script to fix it up so I don't have to watch the apply issue never finish? 3. Is there a CLI if a GUI memory leak issue (not thinking this is the issue or likely, but I am a UNIX guys doesn't hurt to wonder).

 

In the end it is Alpha and I am good with totally restarting and rebuilding my load order if I have too. I am just thinking I cant be the only one that has had to restore a Vortex mod configuration, and curious if this issue has appeared and or been solved in a way I may not have thought of. And in the end if 300+ plugins need an apply and it cant get through them wanted to bring it up an issue to be looked at with Vortex.

 

Thanks for listening, all the wonderful mods, and what is really an excellent tool (even in Alpha).

 

~LokiX1

[Tannin42]

a) You don't have to click on apply on each item, that's just a selection box where you can pick what to do. If you want to apply all you just click continue. Hence why it never finished: You never started.

b) Does your recovered drive contain your game? Otherwise I don't see why Vortex would see external changes at all. If it did you may look into getting a better backup software because this done apparently doesn't understand hard links.

c) regarding memory: Do you actually have any memory issues? Vortex, being based on chrome, will happily just use as much memory as it feels like for caching stuff and give it up if necessary

 

What vortex does is look at the vortex.deployment.json and check if any file that vortex deployed before is no longer a link to the file it came from or has a different timestamp.

You didn't say which kind of change vortex discovered but I will assume all those files were turned from hard links into actual copies by your backup software. You may be easier off purging and then just redeploying.

[lokiX1]

Thanks Tannin. That helps. I used Crashplan, however I also had a local copy manually copied with rsync on my end. Both of which fail. Additionally I tried to deploy on the same system with a fresh Fallout 4 installation (moved the older out of the way) and I can't get it to deploy either. This very much feels like permissions from the error below, however running Vortex as administrator, and administrator, as well as myself have full control over all directories touched.

 

In the end when tailing (with baretail) the log file I see 65k instances like so (all the files i have for the mods):

 

Tue, 17 Apr 2018 22:36:21 GMT - warn: failed to link error=EPERM: operation not permitted, link 'Y:\Vortex\Fallout4\mods\80's Arcade Cabinets-21270-1-0\textures\arcade\arcade_white.dds' -> 'Y:\SteamLibrary\steamapps\common\Fallout 4\data\textures\arcade\arcade_white.dds', link=textures\arcade\arcade_white.dds, source=80's Arcade Cabinets-21270-1-0

 

I then get an error in Vortex stating that something may have a lock on the folder. I don't think so, but still don't see the issue. At this point I have a new system and am going to try to reinstall all the mods in an net new environment. Not sure why this one is not working. I guess the only question I would have is what would cause the link creation to fail in this way? Here are my thoughts:

 

• Would this fail if physical copy of the file is already in place (would a manual copy break the hard links?....which are essentially full files (UNIX guy here, but hard / soft links roughly work the same in winders me thinks) Maybe my manual copy borked something in the fallout data directory?
• Permissions? Seem to be correct, but Vortex cannot link with an operation not permitted error. Sounds a bit like permissions, but they seem good.
• Large amount of '*backup files for esps, etc...) wonder what the cause for these are (was thinking mergemods, or xedit edits, but there are way to many to be that)
• File quantity limitation? Shouldn't be it this as NTFS has limitations much higher that 65k files

 

At any rate just some thoughts if you have a second to ponder (which you don't cause you are busily writing an awesome new mod manager :-D)

 

I will play with it a bit longer to see if I can determine what is the deal, and likely move on to a complete rebuild.

 

Thanks again for your response.

[lokiX1]

Figured out most of my issue. The Permissions really did get scrambled on the drive I use for Fallout and Vortex, but not in a way easy to find (looked good unless you went into advanced permissions and saw one set with access, and another with none. That coupled with some permissions owned by a UUID (likely for the drive, and got that way after a windows install....I think) Once I got past that I was able to deploy half my mods, the other half (or so) would complain that they were not a correct format of ESP. All of those are zero length. I assume in that I did something here as I was restoring, copying data back and forth, etc. Luckily I have all the install files locally and am in the process of reinstalling those mods either from Downloads for vortex or from backups of my own merged mods.

 

All is well and I learned loads about how Vortex works. Plus of all of this is that when I am done I am confident that this will work, and I now realize I can also use Vortex, its profiles, and the mod repository to sync to my laptop to deploy them there for when I travel.

 

Mischief managed it would seem. Of course I am still reinstalling those mods that got zeroed out somehow. But confident when I am done I will be back working again. :-)

[Tannin42]

Great to hear it's working.

 

Yes, permissions on windows are a bit of a mess because there are two permission systems on windows: dos-style file attributes like "read-only" and ACL (access control list) which are inheritable rules (ACEs) like "uuid x is allowed to read, write, change attributes, ... on file y" and then ACLs are combined with "owners" so instead of "uuid x is allowed..." the ACE could also say "the file owner is allowed..." or "the special 'system' user is allowed..." or "the account that created the file is allowed...".

 

When you reinstall windows your user account gets a new uuid so the ACEs that previously gave you write access based to a file/directory based on uuid may no longer apply (whereas others, based on account role could still work).

 

Unfortunately the error message vortex gets (EPERM) does not detail why it doesn't have access so I can't give a more informative error message like "please remove the read-only flag" or "the ACE for your user account only allows read access".