Hi, until very recently (probably 8.1 or 8.2) I was able to sync my Addons and Keybinds across different computers using cloud based storage and symlinks using something similar to this:
After sometime away from the game, I returned now on 8.2.5 and everytime there is an update, Battlenet breaks my setup by deleting my symlinks and re-creating a local version of my WTF and Interface folders.
Has anyone found a turnaround to get this working again?
I wrote a program in C# that monitors my junctions once a minute and recreates them if they get deleted / mangled. It’s been working like a champ. It’s updated twice today and had to recreate them both times for example. Unfortunately I wrote it very specifically for my use case (I have multiple accounts and use junctions to keep them all linked to one directory for my settings), so about the only thing reusable is the library that handles checking and creating junctions in C#.
Writing an external program in C# to recreate your links is not an acceptable workaround.
I expect that whenever an update happens, it is checking the file and folder structure to confirm necessary directories are present, and the symlinks are visible to Windows as non-standard folders, so the Battle.net client creates standard folders, overwriting the links.
File/folder integrity checking honestly seems like a good thing to have, but they should find a way to account for the possibility of symlinks, or failing that, make it an optional toggle that can be turned off per game, at least for WoW and SC2 where user-created content might need to be shared and/or backed up across devices.
In my scenario it’s deleting directories out of my WTF\Account folder and leaving them MIA.
I have the following
WTF\Account\ACCOUNT - My main WoW account, a regular folder
WTF\Account\ACCOUNT2 - (my second account) which is a JUNCTION to ACCOUNT
WTF\Account\ACCOUNT4 - (yes I like powers of 2) which is a JUNCTION to ACCOUNT
WTF\Account\ACCOUNT8 - JUNCTION again
WTF\Account\ACCOUNT16 - JUNCTION (Don’t judge me)
When an update runs, it deletes ACCOUNT2, ACCOUNT4, ACCOUNT8, and ACCOUNT16. So it’s not just deleting junctions it thinks should be regular folders and replacing them, it’s wiping out all junctions it finds.
I started noticing this when Classic launched (about 2 or 3 days after launch), as up until that point it hadn’t even done this in Classic. Than once 8.2.5 dropped for Retail it also happened. Now I’m not sure if it’s actual launcher that is doing this (as it applies the updates), or what. But it’s quite annoying.
And I agree writing a C# program isn’t a fix, but for me it’s eliminated having to constantly check and re-run a batch file when an update occurs. It made it out of mind for me. If it wasn’t for a log I have open on my screen, I wouldn’t even know now.
WTF and Interface folders (and probably others that are less relevant for the purpose of this thread) are generated when launching WoW (on the given account, in the case of WTF). You are saying that these are being deleted when the Battle.net client runs an update? Not when you launch the game following an update?
Correct, as I said I have an app monitoring it. When I woke up this morning, I noticed that it had re-created the junctions over night due to an update. And then it had another update today. These are being deleted as part of the update process, not part of launching the game after the update (as in both these cases I hadn’t launched WoW since yesterday afternoon). There is no reason at all for it to touch something in the WTF\Account folder where there would normally be multiple directories for each account I have logged in on this PC. But it’s still going in there and deleting the junctions. Which would seem to indicate it’s explicitly looking for these junctions (as it doesn’t recreate them as emtpy folders).
And this isn’t the first time I’ve had issues with Blizzard not allowing this. I used to play on Mac’s in the last 2000’s, and since I’ve had these accounts since late Vanilla/Early BC, I used symlink’s on Mac OS X (the unix equivalent of junctions on NTFS). But the game (actually in code) explicitly checked if the folders were a REAL DIRECTORY or NOT (yes I debugged it). I could not come up with ANY VALID reason for it to make that check, nor could I get Blizzard to even respond to me when I asked about it. So it should be clear I write software for a living, everything from end user applications to device drivers over my many years. So I did solve the problem, I wrote a driver that intercepted the calls the app was making to the file system to inquire about these folders, and when it asked about my specific folders, it returned that it was a real folder, not a symlink (but only for those folders). It worked, the game just worked. It just had code there to prevent me from doing this, for NO VALID REASON.
So yes I’ve gone to some crazy levels in the past to work around an issue, and I’m afraid we may never get any attention on this one either, hence why I wrote the app I did sadly.
I’m curious whether a Junction (mklink /J) rather than a symlink (mklink /D) would behave differently.
I work in IT support for a large manufacturer, and some of my downtime prevention methods involve creating symlinks from default program install folders to network shares, and using a nightly robocopy.bat to copy the files back down from the network share to a separate on-device archive.
They tell me that’s easier and less kludgy than what would be needed to prevent network downtime.
I was using mklink /J myself. But I know in either this one or one of the many other threads on this that others are using mklink /D and it’s wiping those out as well. I always used mklink /J as I started this many many moons ago, and mklink /D wasn’t added until Vista. In code I’m using Reparse Points (which is what junctions on NTFS are)
i tried both types of symlink and they keep disappearing. im only using them in classic to link to the retail folder for each addon i write (it works in both so this is, or at least should have been, simpler than push/pulling the thing at every change)
im also not sure if its all update related as there is an issue with win10 destroying symlinks if you have fast start enabled and it does a disk check (i think, i cant remember the exact trigger)
someone posted a solution where they removed everyones ability to delete the symlink from the permissions list for it, which i suppose could be a viable alternative here as well.