I have a dual boot configuration composed of Windows 7 and Windows 10. Both are configured a C: disk as system and D: as data disk, which includes Users directory. And I have also another (physical, too!) disk, let's call it V:, with photos and other stuff.

On Windows 7, to access photos from D: disk I've made a symbolic link (junction) like this (historical reasons):

mklink /j d:\photos v:\photos

And I can fully access all folders in d:\photos. So I tried to do the same on Windows 10, but it's not working properly as I wish. I can enter the d:\photos, but no other sub-directory is accessible neither I can write anything inside d:\photos. But I can access v:\photos without problems...

If I click with the Windows Explorer on for ex. d:\photos\folder1, I get "The system cannot move the file to a different drive". If I check security tab on that folder, I find the message "The requested security information is either unavailable or can't be displayed".

I've already tried a few things, but without success. Can be the problem that C: and D: are on the same SSD, and V: is another HD? Any ideas what to do?

Thanks!

  • I have an extremely similar problem since I updated the system from Windows 7 to Win 10. I had a link (Junction) from "D:\games\strategy\Starcraft II" to "J:\games\blabla\starcraft II" which is exibiting the same problem. Deleting and re-creating it does not help. However creating the very same junction starting from "C:\Program Files (x86)" works. C: and E: are different partitions of the same SSD, J: is a rotating disk and J:\Games is an NTFS mount point for an SSD. Maybe you can try to create a Junction from C:\Program Files to confirm this is the same problem of not... – Simone Avogadro Jun 18 '16 at 10:59

While junctions are supported across local drives, you will probably have better luck with actual directory symbolic links. Win7 (everything since Vista, more specifically) supports these, though XP and older do not. Symlinks store actual destination names (so, as long as the other drive is V: on both OSes, it should work). My best guess is that junctions may use an identifier other than drive letter and when you switch OSes, some of that identifying data isn't understood by the other OS. They obviously don't just use the name, or you would be able to make a junction to a mapped network drive, and you can't.

The syntax to create a true symlink for a directory is the same as creating a junction, except use the /D flag for mklink, rather than /J. Note that, by default, only Administrators can create symlinks (not sure why this is enforced for symlinks and not for junctions, but c'est la vie). So, launch Command Prompt as Admin (and yes, it must be CMD; mklink is a CMD built-in, not its own executable that could be called by, say, Powershell) and try mklink /d d:\photos v:\photos.

Note that you can also use mklink without any flags to create file symlinks, or with the /H flag to make file hard links. Not relevant here, since you're trying to link directories rather than files, but potentially useful info for the future. Most people aren't aware that NTFS supports hard links (since... Windows 2000, I think?) and symlinks (since Vista), even if they know about junctions (which aren't quite a full symlink, or you could create one to a network drive).

  • I've tried also directory symbolic links, but without success. Still cannot access... But ... you know what is working... symbolic links to the C: disk. So instead of v: I connect with c:, which is the system drive... – Sajmon Jan 26 '16 at 7:09
  • Hmm... I wonder if the problem might be NTFS symlink evaluation settings? Try running the following command: fsutil behavior query symlinkevaluation. Normally local-to-* is allowed, and remote-to-* is blocked. Although, with that said, the behavior you described doesn't sound like the normal result of symlink evaluation being blocked. – CBHacking Jan 26 '16 at 20:38
  • Result is normal: local-to-* enabled, remote-to-* disabled... – Sajmon Jan 27 '16 at 18:00

I had the same issue; this seems to be caused by changing the install location of apps to another drive.

What solved it for me was setting the save location for new apps back to C, and then rebooting into command prompt (hold shift while restarting) and deleting "System Volume Information\wpappsettings.dat" on the drive in question.

Has same problem: has disk C:(new windows10) D:(old) E:(old)

I can create directory junction from D to C (for "Program Files" subfolders etc.), but can't do same from E to D: junctions created but I can't see files contents and subfolders with same error.

Don't understand why, but all solved by loading Ubuntu and deleting "D:\System Volume Information" (It was recreated by Win10 after).

PS. Has normal result fsutil behavior query symlinkevaluation: local-to-* enabled, remote-to-* disabled

I run into a similar problem a while before which were caused by permission system. In my case i had a unc-path as target, permissions and share had been configured correct. In the unc-path i was able to create links and dive into subfolders, in the symbolic folder not. Inherit rights from the top folders had been the reason.

Try to disable inherit permissions for the symbolic folder and remove permissions which may cause problems. Set explicit permissions to gain full control in the symbolic folder. In my case, it solved the problems and i had been able to create links and dive into the subfolders.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.