MacOSX filesystems use extended attributes (e.g. "com.apple.quarantine", "com.apple.FinderInfo"):
$ ls -l@ .DS_Store -rw-r--r--@ 1 gareth staff 18436 2 Nov 10:35 .DS_Store com.apple.FinderInfo 32
- Can these extended attributes be stored across an NFS mount at all?
- Can these extended attributes be stored across an NFS mount of an ext4 filesystem? That is, so that an extended attribute on an HFS+ file (seen with xattr -l ) can be seen in some way on the ext4 file system (with getfattr -d ).
A problem appears to be that ext4 file systems require user attributes to begin with "user.", which makes it incompatible with MacOSX: E.g. the following command works on Linux because the name starts with "user."
Linux# setfattr -n "user.hello" -v "some data" examplefile
but the following fails:
Linux# setfattr -n "com.apple.Finder" -v "some data" examplefile setfattr: examplefile: Operation not supported
So could extended attributes ever be stored, unless they were automatically renamed? E.g. "com.apple.Finder" could be stored as "user.com.apple.Finder".
I have tried to research this using a MacOSX NFS client to mount a Debian Linux NFS server. (Finder -> Go -> Connect to Server...) The mount appears to work but as soon as the GUI tries to browse it tries to create a .DS_Store file with extended attributes and the whole NFS connection locks up and fails. (At least, I think that's the reason it fails. I was able to copy a small file without attributes, before attempting to browse.)
Any insights in to this question will be appreciated. Thanks!