1

I have a Windows application which worked as expected when files that the application uses are actually on C drive (the same drive as the application). I then moved the files to D drive and have tried creating both symbolic links and junctions on C drive to the directory on D drive such that the moved files appear as they did before moving them to D drive. Now it appears the application can read the files but can not update the files or install new files.

Specifically, I have been attempting to move oculus rift games from C to D drive and creating symbolic links such that the directory containing the games still appears on C drive. I have been successful with respect to playing the games. However, I have not been able to update games or install new games. I have attempted to allow write permissions to all directories and files. And I have tried to change the ownership of the files using Cygwin. So far I have never been able to update an existing game or install a new game while the games exist on D drive with symbolic links back to C drive.

st2000
  • 286
  • 1
  • 16
  • Thank you @ErykSun for your comment. I am trying to understand why Windows links do not work as expected. And what I can do to fix them so that they do work as expected. Are you saying that the write permissions on D drive do not matter because they are not considered by the application? – st2000 Dec 25 '19 at 22:47
  • I removed the link from my question. I don't think JUNCTIONS work for my case. As I am linking to files on a different HDD, I believe my only option is to create symbolic links. I will double check, but I believe I created a new directory on D then moved all the files within the old directory on C drive to the new directory on D drive. After, I deleted the old directory on C drive then created a link from C drive to the new directory on D drive. – st2000 Dec 25 '19 at 23:30
  • A junction to the new directory will behave like a bind mount point in this case, and it will be allowed as long as drive "D:" is a local device. That's an important distinction that makes mount points irreplaceable in paths that get accessed remotely. Symlinks won't work in that case since they always get evaluated on the client side, which has no direct access to devices on a remote machine. – Eryk Sun Dec 25 '19 at 23:42
  • 1
    I have now created / tested junctions and symbolic links. Neither allow the Application to update files that are flagged as being in need of an update. When creating the junction, the "read only" block under permissions is "black boxed". I clicked it to make it "white boxed" and applied this to all directories and files. After about 60 seconds the operation is finished. I click OK closing the dialog. I then right click on the junction directory and display the properties pop up again. The read only "black box" has returned. The application still can not update the file of interests. – st2000 Dec 26 '19 at 01:07
  • Setting a directory as readonly only applies to the directory entry itself, not its contents. It's pretty much useless since only an empty directory can be deleted anyway. The Windows desktop shell reuses this flag on customized directories to indicate that the "desktop.ini" file should be read. – Eryk Sun Dec 26 '19 at 02:06
  • A directory symlink reparses to its target, and the security on the symlink is not evaluated. For this simple case, a junction is pretty much the same, except the security on the junction is checked when the directory is opened to read its attributes (e.g. time stamps) or list it (read data). Without a failure log, it's not possible to help much here, and even if you had one, that wouldn't be on topic. You'd have to move the question to Super User. – Eryk Sun Dec 26 '19 at 02:14

0 Answers0