Re: [PATCH] Compatibility improvement to reparse point handling, v3

[Joe Lowe <joe at pismotec dot com>]

On 2017-06-19 04:45, Corinna Vinschen wrote:> Hi Joe,
> 
> As discussed in the previous iteration of this patch, this change
> results in nuking DT_UNKNOWN for reparse points we don't handle.  Still,
> IMHO, if we have reparse points we know nothing about, they should stay
> DT_UNKNOWN.
> 
> Why is changing them to DT_DIR/DT_REG a good idea?  Please convince me.

As coded, the patch makes the dentry.d_type field consistent with
S_ISREG and S_ISDIR on the results of lstat-ing the same name. This
seems correct to me, from the standpoint of avoiding compatibility
issues with any *nix application code that may look at the d_type
value and make some inference from it. I do not know of any specific
application examples where this is actually a problem.

My concern with DT_UNKNOWN for unknown reparse tags: it indicates
to cygwin applications and developers that reparse tags are an
extended file system node type enumeration. In general this is
incorrect. Reparse tags are a type of extended attribute that can be
attached to any regular NTFS file or directory. Reparse tags do not
necessarily do anything to prevent normal access to the
file/directory.

If you like, I will redo the patch to return dentry.d_type of
DT_UNKNOWN for files/directories with unknown reparse tags.
Let me know.


Reference, discussion of compat issue between msys-git (likely in
downstream cygwin code) and Windows server file deduplication:

http://git.661346.n2.nabble.com/FW-Windows-Git-and-Dedupe-td7579993.html
"The reparse point could be decoded as being a non-symlink reparse
item using; in those cases, treating the file as an ordinary file
would be appropriate."

Reference, blog post from AFS developer:

http://blog.secure-endpoints.com/2013/03/symbolic-links-on-windows.html
"For the longest time I resisted squatting on Microsoft's tag and
data structure but as long as FSCTL_GET_REPARSE_POINT returns the
IO_REPARSE_TAG_OPENAFS_DFS data many applications do the wrong
thing. There simply wasn't any choice from the perspective of
application compatibility."


Joe L.