Directory Junction keeps being deleted

Question

I have upgraded from Windows 7 to 10 Professional on an SSD and I have created Directory Junctions, using command line mklink /J, for folders like Games, Mozilla Profiles, etc. pointing to a HDD directory. All of the junctions work well except for Mozilla Firefox profile which is linked like this:

Junction created for C:\Users\[USERNAME]\AppData\Roaming\Mozilla <<===>> H:\Users\[USERNAME]\AppData\Roaming\Mozilla

Although this junction works fine when created, at random intervals it is being deleted. Either after computer sleep the junction is missing, or after a restart, or anytime while using the computer. It doesn't happen every time I restart the computer or put it to sleep, etc. It seems to be completely random.

I tried Directory Symbolic link as well (mklink /D), but the same happens. Interestingly enough, I don't face any problems with the other junctions on the same volume H:

There are no issues with NTFS permissions and volume H: is a fixed HDD (not a removable one).

Any ideas what is causing this?

Answer 1

PortableApps is causing the deletion of the junction but the problem lies within Windows rmdir command. According to this thread on PortableApps forum, all applications packaged in PortableApps format, rely on rmdir to remove any leftover folders that might be created by the portable application. rmdir can remove an empty folder, will provide an error if the folder is not empty, but when used against a junction it just deletes the junction itself.

Portable Applications that use the AppData\Roaming\Mozilla folder, remove the junction when closed. Such portable applications include Seamonkey, Firefox Developer Edition, Firefox, etc.

Currently there seems to be no solution or workaround to this problem from the PortableApps side. There is though one thing that can be done to prevent the junction from being deleted. Instead of creating a junction (mklink /j) we can create a symbolic link (mklink /d) and then edit NTFS permissions on the symlink, adding Everyone Deny Full. I came up with this solution after reading this SU thread.

Answer 2

I was able to fix the problem by disabling Fast Startup in the Windows 10 Control Panel Power Options. It's hard to find; look for "Change what the power button does" in the left margin of the old-version control panel. Once found, it claims to be filed under:

Control Panel > All Control Panel Items > Power Options > System Settings

To be clear, it appears that in recent releases of Windows 10, chkdsk.exe gets triggered during certain restart scenarios (?). For my case, this in turn caused all my permanent, manually-established cross-volume NTFS reparse points ("directory junctions") to be deleted en masse.

The default setting for Fast Startup was changed to 'enabled' in the Creators Update 1709, which, at least for my case, may explain how the previously unseen problem was introduced. See here for further info.

Seems that the real culprit may be chkdsk.exe itself, regardless of the triggering scenario, 'Fast Startup' or otherwise. It is true--and simple to demonstrate--that explicitly running chkdsk.exe on a particular NTFS volume seems to fully remove any and all all cross-volume reparse points. Or at least for those established using the \\?\Volume{a6f7f7de-091e-4234-81a0-947ebba1bf3c}\ path notation, which is all I ever use for these, and thus all I can report on here:

Create a cross-volume Hard Link, e.g.

X:\foo> linkd bar \\?\Volume{ce775273-ab33-47af-8fac-1abdb60a0690}\baz

This establishes a cross-volume hard link ("junction" or "NTFS reparse point") where X:\foo\bar is redirected such that it equals directory \baz on the specified volume, but such links will be deleted whenever chkdsk.exe is subsequently run on the source NTFS volume X: