When junctions are hidden, also hide from left pane #297
Conversation
|
Used it as part of #303 and it worked fine. |
src/lfn.c
Outdated
| lpFind->fd.dwFileAttributes |= ATTR_SYMBOLIC; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
This code is a much better way to do what DecodeReparsePoint does. We should be able to remove one or both calls to DecodeReparsePoint.
There was a problem hiding this comment.
You might want to omit evaluating attributes returned from DecodeReparsePoint() in general, but you can't remove the call to it in wfdirrd.c:781, because it delivers szLinkDest, which is needed. You might omit the call to it in wfdirrd.c:915
There was a problem hiding this comment.
I changed the one caller that can be changed.
| @@ -85,8 +92,10 @@ WFFindFirst( | |||
| lpFind->nSpaceLeft = MAXPATHLEN-nLen-1; | |||
|
|
|||
| if (lpFind->hFindFile != INVALID_HANDLE_VALUE) { | |||
| DWORD compareAttributes; | |||
| compareAttributes = lpFind->fd.dwFileAttributes & ATTR_USED; | |||
| lpFind->dwAttrFilter = dwAttrFilter; | |||
There was a problem hiding this comment.
This is not necessary as lpFind->fd.dwFileAttributes was already combined with ATTR_USED.
There was a problem hiding this comment.
lpFind->fd.dwFileAttributes are combined with ATTR_USED, then ATTR_JUNCTION/ATTR_SYMBOLIC are added (which are not part of ATTR_USED), then this compare occurs. The intention was not to compare against ATTR_JUNCTION/ATTR_SYMBOLIC. Another approach would be to perform this compare, and if the entry is filtered call FindNext (which adds them); if the entry is not filtered then add them here.
There was a problem hiding this comment.
I changed this to the alternate approach which avoids the back-and-forth conversion, effectively setting ATTR_JUNCTION/ATTR_SYMBOLIC after the decision to return the entry has already been made.
| } | ||
| } | ||
| break; | ||
| } | ||
| } |
There was a problem hiding this comment.
This block and the one above at line 676 are doing essentially the same thing. Can we create a method to "SkipJunctionPoints" or something like that?
malxau
force-pushed
the
HideJunctions
branch
from
9ee462d to
1cfc191
Compare
* Solves to problem of winfile following reparse point during deletion of trees and causing ahrm to linked directories * Also skip one entry in the destination. Not needed during deletion, because there is no destination during delete. * Adapt to #297. This makes the situation much easier * Don't follow Reparse Points by using OPER_RMDIR during delete Co-authored-by: schinagl <hermann@schinagl.priv.at> Co-authored-by: Hermann Schinagl <hermann.schinagl@avl.com>
This is to fix #268 . Although it's not what the title says, looking closer at the screenshots, the concern is around seeing junctions in the left pane (which the user does not have access to), even though the setting for "Show Junction Points" is disabled.
This change leverages
dwReserved0to identify the reparse tag, which is now documented behavior but has existed since reparse points were added in Windows 2000. I followed the pattern of having the caller filter junctions, which is not optimal - withdwReserved0it should be possible to usedwAttrFilterfor Junctions too, but that requires carefully scrubbing the code to ensure it's propagated. Most of this change is about propagating it in the left hand pane enumerate.Also, I'm not stepping back from my comment that the "real" fix is to not have a race condition enumerating the left pane. That change seems large and complex enough that it's likely to introduce bugs and unlikely to be accepted. But the advantage of doing it is to eliminate "network hangs" by doing file system operations on the UI thread, which the current code can't achieve.