[Symbolic Links] Please add an option to hide Symbolic Links
dftf-stu opened this issue · comments
Would it be possible in a future update to add a setting into the "By File Type" dialog to hide Symbolic Links please?
I want to see Hidden and System files, but when that setting is turned-on, Symbolic Links also get displayed, which I'd rather not see as accidentally doing a delete or move on them can be destructive. For example, if a user were to browse into C:/Users/username/Documents, they will see "My Music", "My Pictures" and "My Videos". If they delete or move any of these "folders", the action will occur on the target -- so files could accidentally be destroyed!
Some examples of Symbolic Link "folders" which appear currently:
Sry I object. Symbolic Links are part of NTFS and should be there.
I assume 'Hide Junctions' is just there, because junctions are outdated and basically superseded by Symbolic Links, which are much more generic. One can also create symlinks to files and not to just directories.
Junctions ... Why are they available? I guess they were a byproduct of volume mountpoints, which nowadays are never used, but had to be there, because in the former days NTFS was matching with Unix filesystems, and mounting is pivotal with Unix.
On the other hand, why did they not enable Symlinks with XP? or W2K, because it was there in NTFS and could be enabled with a filter driver. Ah these are all stories from a former version of the Matrix ;-)
But just guessing. I am sure there are people here who can answer much better ;-)
I think this issue is confusing things. "My Music", "My Pictures" et al aren't Symbolic Links, they're Junctions. I don't know for sure, but I'll bet this is the reason Craig added the "Show Junction Points" option - the Junctions included in Windows by default are better off hidden.
There are a lot of subtle differences between Junctions and Symbolic Links. One difference is the way ACLs are evaluated. Junctions apply their ACL before redirecting, which is how these internal links work - they have a DENY ACE for FILE_LIST_DIRECTORY, so requests can be redirected to the target, but FILE_LIST_DIRECTORY will never be granted. So these links couldn't become Symbolic Links and still fulfill their intended purpose - it's not because they're old, it's because they depend on Junction behavior.
I think this issue is identifying a different problem. When "Show Junction Points" is off, WinFile is hiding Junctions in the right hand pane, and it will hide Junctions in the left hand pane when a new directory is expanded/enumerated. But it does not hide Junctions on parent directories that were enumerated incidentally. If you ensure "Show Junction Points" is off and open WinFile in any directory other than the root, "Documents and Settings" is still displayed. Because WinFile doesn't have access to it, its behavior when operating on it is...truly inexplicable. If you collapse the tree by double clicking C:\ in the top left, then reexpand, it won't be displayed again.
I think the problem is in ReadDirLevel, and the way initialization is a giant race condition. Each window has a thread running CreateDTABlockWorker populating an in-memory structure of objects. ReadDirLevel can consume from that (if it exists, see GWL_HDTA), and if not, it calls WFFindFirst. WFFindFirst can apply attribute filters known to the file system, but ATTR_JUNCTION is a contrived one - all the file system sees is FILE_ATTRIBUTE_REPARSE_POINT. The logic for ATTR_JUNCTION is implemented in CreateDTABlockWorker, but if ReadDirLevel enumerates itself, it's missing this logic.
Should add: I think the real fix is to have the async thread populate the in-memory structure, and when it's done, tell the tree to consume from that structure. That's a fairly large change. Obviously the "original" code couldn't generate this on a background thread, since it was 16 bit. The 16 bit code relied on wfYield to let other applications run. Depending on the async thread implies ensuring that background population is robust and synchronized.