Ok, some weeks and several rsync sessions later, I have a clearer picture of what is going on.
Overall, the meta-data situation with 2.1.6 seems as follows:
Extended AttributesSupported by ZFS 2.1.6 and fastest if using the
-xattr=sa option when creating a dataset.
Two Exceptions: com.apple.FinderInfo and com.apple.ResourceFork extended attributes that are empty (all 0) get dropped / ignored by ZFS 2.1.6.
(actually, it might be that any empty xattr gets dropped - I saw some empty 'com.apple.assetsd.title' attributes which I couldn't sync to ZFS 2.1.6.
On the other hand, on Ventura I can write an all-0 xattr as long as it is not com.apple.FinderInfo - only then this also fails on APFS)
Resource ForksResource forks are actually stored as com.apple.ResourceFork extended attribute and as long as they are not empty, they are supported by all extended attribute-based methods. For example, a
rsync --xattrs correctly copies resource forks as long as they are not empty or all 0s. Empty resource forks get simply ignored by ZFS.
Important: The Posix mapping of Apple resource forks to a special file path (FILENAME/..namedfork/rsrc) seems unsupported by ZFS 2.1.6, and any software trying to do so (e.g. Finder, or the Backup Bouncer scripts I reported above) fails.
com.apple.FinderInfoSimilar situation: get copied correctly as extended attributes
unless they are empty or all-0s. Worthwhile noting, ZFS 2.1.6 zeros out some internal extended fields in the FinderInfo structures. So after copying onto 2.1.6 datasets, bytes 16 to 24 of the FinderInfo attributes are always 0 even if they were set in the original; and if the masking of those bytes makes the whole FinderInfo structure all 0, it doesn't get stored at all. While this doesn't seem to affect any of the 'official' usage of FinderInfo attributes, e.g. for tagging a file with colour flags in Finder, it is quite annoying if you try to rsync from an older ZFS dataset which had such FinderInfo attributes on some of its files...
This also can have the strange side-effect that when accessing an existing dataset which contains all-0 com.apple.FinderInfo attributes, you can list them in a shell, but you cannot read them:
- Code: Select all
ls -l@ "/Volumes/PhotoSnapshot/Photos Library.photoslibrary/Photo Database"
-rw-rw-rw-@ 1 user group 696 9 May 2015 /Volumes/PhotoSnapshot/Photos Library.photoslibrary/Photo Database
com.apple.FinderInfo 32 [<-- note, non-empty but all zero]
com.apple.quarantine 46
xattr -lx "/Volumes/PhotoSnapshot/Photos Library.photoslibrary/Photo Database"
com.apple.FinderInfo:
00000000
com.apple.quarantine:
00000000 30 30 38 36 3B 35 38 38 30 33 39 33 33 3B 50 68 |0086;58803933;Ph|
00000010 6F 74 6F 20 4C 69 62 72 61 72 79 20 4D 69 67 72 |oto Library Migr|
00000020 61 74 69 6F 6E 20 55 74 69 6C 69 74 79 3B |ation Utility;|
xattr -px com.apple.FinderInfo "/Volumes/PhotoSnapshot/Photos Library.photoslibrary/Photo Database"
[nothing]
BSD FlagsBSD flags seem supported on ZFS 2.1.6
except the user immutable (uchg) and the archived (arch) flags. The uchg is the flag which is used by Finder to 'Lock' a file or directory... This also means that the shell commands
SetFile -a l FILENAME and
chflags uchg,arch FILENAME do not work.
Warning: I think rsync v3.2.7 has a bug in its
--fileflags option which mangles the BSD flags during copy... I had problems with it during remote syncs.
ACLsI have not been successful in getting any ACLs copied or manually set on a ZFS 2.1.6 dataset, regardless of which settings I tried. It seems ACLs are currently unsupported.
What does this mean? Does any of this matter?
I would say yes: This thread started with the problem that user-defined Finder Icons and locking of files in Finder does not work on ZFS 2.1.6.
The reason is that ZFS 2.1.6 does not support the 'uchg' BSD flag (which is used by Finder to lock a file) and that Finder seems to store icons as a named resource fork using the "FILENAME/..namedfork/rsrc" special pathname which is not supported by ZFS 2.1.6.