lundman wrote:but as you point out "com.apple.FinderInfo" is not allowed to be all zero.
[...]
So possibly ZFS clears out too many fields? and accidentally make it all zero, then we remove it. The trick will be figuring out how much to actually
zero.
Indeed, this is tricky as it seems not well documented.
I experimented with APFS under macOS 13.2 and with ZFS 2.1.6:
Test 1: Zeroed and Empty Extended Attributes- Code: Select all
touch testfile-apfs
xattr -wx com.apple.ResourceFork 0000000000000000000000000000000000000000000000000000000000000000 testfile-apfs
xattr -wx com.apple.FinderInfo 0000000000000000000000000000000000000000000000000000000000000000 testfile-apfs
xattr -wx org.home.zeroattr 0000000000000000000000000000000000000000000000000000000000000000 testfile-apfs
xattr -w org.home.emptyattr "" testfile-apfs
ls -l@ testfile-apfs
-rw-r--r--@ 1 user staff 0 18 Feb 13:16 testfile-apfs
com.apple.ResourceFork 32
org.home.emptyattr 0
org.home.zeroattr 32
xattr -lx testfile-apfs
com.apple.ResourceFork:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
org.home.emptyattr:
00000000
org.home.zeroattr:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
Zeroed ResourceForks are possible, but note that the all-zero FinderInfo quitely gets dropped by APFS.
Also note that I can write an empty extended attribute as long as it is neither FinderInfo, nor ResourceFork.
ZFS 2.1.6 is consistent in not writing an all-zero FinderInfo, but it also does not allow any empty extended attribute, regardless of its name, which is more restrictive than APFS:
- Code: Select all
touch testfile-zfs
xattr -wx com.apple.ResourceFork 0000000000000000000000000000000000000000000000000000000000000000 testfile-zfs
xattr -wx com.apple.FinderInfo 0000000000000000000000000000000000000000000000000000000000000000 testfile-zfs
xattr -wx org.home.zeroattr 0000000000000000000000000000000000000000000000000000000000000000 testfile-zfs
xattr -w org.home.emptyattr "" testfile-zfs
xattr: [Errno 93] Attribute not found: 'testfile-zfs'
ls -l@ testfile-zfs
-rw-r--r--@ 1 user wheel 0 18 Feb 13:12 testfile-zfs
com.apple.ResourceFork 32
org.home.zeroattr 32
Test 2: Masking of FinderInfo bytesIn APFS, at least with macOS 13.2, it seems to write the whole FinderInfo without masking, as long as it is non-empty and not all-zeros:
- Code: Select all
touch testfile2-apfs
xattr -wx com.apple.FinderInfo 5445585431313131313131313131313131313131313131313131313131313131 testfile2-apfs
ls -l@ testfile2-apfs
-rw-r--r--@ 1 user staff 0 18 Feb 13:21 testfile2-apfs
com.apple.FinderInfo 32
xattr -lx testfile2-apfs
com.apple.FinderInfo:
00000000 54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31 |TEXT111111111111|
00000010 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 |1111111111111111|
00000020
This also works on symbolic links, and also note that symbolic links cannot have a resource fork:
- Code: Select all
ln -s testfile2-apfs testlink-apfs
xattr -ws org.home.attribute "00000000000000000000000000000000" testlink-apfs
xattr -wsx com.apple.FinderInfo 5445585431313131313131313131313131313131313131313131313131313131 testlink-apfs
xattr -ws com.apple.ResourceFork "00000000000000000000000000000000" testlink-apfs
xattr: [Errno 1] Operation not permitted: 'testlink-apfs'
ls -l@ testlink-apfs
lrwxr-xr-x@ 1 user staff 14 18 Feb 13:31 testlink-apfs -> testfile2-apfs
com.apple.FinderInfo 32
org.home.attribute 32
xattr -lsx testlink-apfs
com.apple.FinderInfo:
00000000 54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31 |TEXT111111111111|
00000010 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 |1111111111111111|
00000020
org.home.attribute:
00000000 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000010 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000020
In contrast, ZFS 2.1.6 masks out several bytes in the extended FinderInfo structure (last 16 bytes):
- Code: Select all
touch testfile2-zfs
xattr -wx com.apple.FinderInfo 5445585431313131313131313131313131313131313131313131313131313131 testfile2-zfs
ls -l@ testfile2-zfs
-rw-r--r--@ 1 user wheel 0 18 Feb 13:26 testfile2-zfs
com.apple.FinderInfo 32
xattr -lx testfile2-zfs
com.apple.FinderInfo:
00000000 54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31 |TEXT111111111111|
00000010 00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00 |........1111....|
00000020
For symbolic links, ZFS 2.1.6 masks out even more fields, including the fdType and fdCreator fields.
But then apparently to make up for this, it allows to create a ResourceFork xattr on the symbolic link
- Code: Select all
ln -s testfile2-zfs testlink-zfs
xattr -ws org.home.attribute "00000000000000000000000000000000" testlink-zfs
xattr -wsx com.apple.FinderInfo 5445585431313131313131313131313131313131313131313131313131313131 testlink-zfs
xattr -ws com.apple.ResourceFork "00000000000000000000000000000000" testlink-zfs
ls -l@ testlink-zfs
lrwxr-xr-x@ 1 user wheel 13 18 Feb 13:35 testlink-zfs -> testfile2-zfs
org.home.attribute 32
com.apple.FinderInfo 32
com.apple.ResourceFork 32
xattr -lsx testlink-zfs
com.apple.FinderInfo:
00000000 00 00 00 00 00 00 00 00 31 31 31 31 31 31 31 31 |................|
00000010 00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00 |................|
00000020
org.home.attribute:
00000000 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000010 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000020
com.apple.ResourceFork:
00000000 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000010 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000020
Disclaimer: I am just observing and comparing the extended attribute behaviour from APFS and ZFS here; I do not claim to know the semantics of the FinderInfo, especially its extended part - and I haven't checked the hfs or apfs documentation from Apple... Also note that I checked on APFS, while the zfs code is referring to the hfs documentation.