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