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.
