Hi,
On Wed, Aug 19, 2020 at 9:06 PM Jean-Pierre André
<jean-pierre.an...@wanadoo.fr> wrote:
> Linux uses the extended attribute paradigm for data which
> are not really extended attribute, in particular for security
> data (Posix ACLs, SELinux, ...), and ntfs-3g has added more
> such attributes (reparse data, object_id, etc.)
macOS does the same thing, but under an "openxattr" namespace starting
with com.apple. Examples include[1] and [2].

  [1]: 
https://eclecticlight.co/2020/01/30/quarantine-sip-and-macl-macos-per-file-security-controls/
  [2]: https://github.com/osxfuse/osxfuse/wiki/Mount-options#extended_security

> Is changing ENODATA to ENOATTR likely to be safe for
> data which is not perceived as an extended attribute ?

No, so some careful choosing will be needed. Examples should include:
* ntfs_fuse_getxattr(), ntfs_fuse_setxattr()
* the bunch of stuff called from ntfs_xattr_system_getxattr() and
ntfs_xattr_system_setxattr()

> Also, you mentioned ea.c, dealing with EAs which were not
> used by Windows until Windows 10. Is MacOS making some
> use of EAs, and more precisely are EAs used on MacOS to
> implement the generic concept of extended attributes ?
Oops, I did not realize until now that the ea.c is referring to the
OS/2 compatible EA, not the ADS. Apologies for the confusion. (The
xattr.c stuff does end up referencing ea via "system." attributes
though.)

> Now, Linux does not define ENOATTR any more, though
> there still are mentions of it in several man pages.

That's... unhelpful of Linux to do that.

Regards,
Mingye


_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to