Problems with xattr / v2.1.6 Monterey (Intel)

[lundman]

and finally

https://github.com/openzfsonosx/openzfs ... f3b8810f71

do we need a pkg now?

[lundman]

Here is an Intel/Catalina (and above) pkg

OpenZFSonOsX-2.1.99-Catalina-10.15.pkg

(16.33 MiB) Downloaded 369 times

[o3x_prokyon]

@lundman: Thanks for the patched pkg! My own try to compile it didn't work... I will try the new version and report back.

Thanks for the patch on ACLs, lundman!
You seem to really have a run at the moment

Regarding the earlier discussion about the changing of FinderInfo xattrs:
Would it be an idea to make this extended attribute behaviour dependent on the com.apple.mimic property of a dataset?
Like keeping all extended attribute unchanged if mimic is not set to hfs?

...or apfs!

[o3x_prokyon]

...hmm! That's strange... I have completely deinstalled the previous version 2.1.6, rebooted and installed the package "OpenZFSonOsX-2.1.99-Catalina-10.15.pkg" from your previous post. But still neither locking directories (uchg) nor setting icons work. It's all the same as in 2.1.6... Switching "kstat.zfs.darwin.tunable.zfs.xattr_compat" from 1 to 0 and vice versa didn't change anything, either. Only applying the system immutable flag (schg) with "sudo chflags schg /dir" is still possible.

Did I get something wrong?

[lundman]

Thanks for the patch on ACLs, lundman!
You seem to really have a run at the moment

Regarding the earlier discussion about the changing of FinderInfo xattrs:
Would it be an idea to make this extended attribute behaviour dependent on the com.apple.mimic property of a dataset?
Like keeping all extended attribute unchanged if mimic is not set to hfs?

OK are you saying you want to be zeroing of fields in FinderInfo based on the mimic setting? In what direction?

Code: Select all

mimic:    zeroing
ZFS       none
HFS       yes
apfs      none


or?

[lundman]

Only applying the system immutable flag (schg) with "sudo chflags schg /dir" is still possible.

OK checking uchg and schg on directories.

This is APFS, and how it should work:

Code: Select all

# mkdir /tmp/dir
# sudo -u lundman chflags uchg /tmp/dir         
chflags: /tmp/dir: Permission denied
// Not allowed as it is not owned by lundman...

# chown lundman /tmp/dir
# sudo -u lundman chflags uchg /tmp/dir
# ls -lOd /tmp/dir         
# drwxr-xr-x  2 lundman  wheel  uchg 64 Feb 20 08:53 /tmp/dir

# sudo -u lundman chflags nouchg /tmp/dir
# ls -lOd /tmp/dir
# drwxr-xr-x  2 lundman  wheel  - 64 Feb 20 08:53 /tmp/dir


# sudo -u lundman chflags schg /tmp/dir
chflags: /tmp/dir: Operation not permitted
// Not allowed as System-chg can only be set by root

# chflags schg /tmp/dir    // this time as root
# ls -lOd /tmp/dir
drwxr-xr-x  2 lundman  wheel  schg 64 Feb 20 08:53 /tmp/dir

# chflags noschg /tmp/dir
# ls -lOd /tmp/dir       
drwxr-xr-x  2 lundman  wheel  - 64 Feb 20 08:53 /tmp/dir


Comparing that with ZFS we get:

Code: Select all

# mkdir /Volumes/BOOM/dir3
# sudo -u lundman chflags uchg /Volumes/BOOM/dir3
chflags: /Volumes/BOOM/dir3: Permission denied
// As expected


# chown lundman /Volumes/BOOM/dir3
# sudo -u lundman chflags uchg /Volumes/BOOM/dir3
# ls -lOd /Volumes/BOOM/dir3
drwxr-xr-x  2 lundman  wheel  uchg 2 Feb 20 09:07 /Volumes/BOOM/dir3

# sudo -u lundman chflags nouchg /Volumes/BOOM/dir3
chflags: /Volumes/BOOM/dir3: Operation not permitted
// Oops BUG 1

// Changing dir names to keep tests separate
# mkdir /Volumes/BOOM/dir4
# chown lundman /Volumes/BOOM/dir4                                                             
# sudo -u lundman chflags schg /Volumes/BOOM/dir4
chflags: /Volumes/BOOM/dir4: Operation not permitted
// So far so good

# chflags schg /Volumes/BOOM/dir4
# ls -lOd /Volumes/BOOM/dir4
drwxr-xr-x  2 lundman  wheel  schg 2 Feb 20 09:08 /Volumes/BOOM/dir4

# chflags noschg /Volumes/BOOM/dir4
# ls -lOd /Volumes/BOOM/dir4
drwxr-xr-x  2 lundman  wheel  - 2 Feb 20 09:08 /Volumes/BOOM/dir4


So it looks like Bug1 is the only issue? Any other combinations?

[lundman]

https://github.com/openzfsonosx/openzfs ... a3d98e97e7

[roemer]

OK are you saying you want to be zeroing of fields in FinderInfo based on the mimic setting? In what direction?

Code: Select all

mimic:    zeroing
ZFS       none
HFS       yes
apfs      none


This sounds about right - though if someone could check the FinderInfo behaviour also on some older OSX versions, it would be good.
I just tried it on macOS 13.2 Ventura with the internal SSD on APFS, and a disk image which I formatted as HFS.
At least for Ventura, the behaviour seems file system dependent with HFS masking out the same bytes than ZFS, while the APFS results are as I reported above:

Code: Select all

# pwd: on an HFS-formatted disk image:
touch testfile-hfs
xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile-hfs
xattr -w  com.apple.ResourceFork "00000000000000000000000000000000" testfile-hfs
ls -l@ testfile-hfs
-rw-r--r--@ 1 user  staff  0 20 Feb 13:21 testfile-hfs
   com.apple.FinderInfo   32
   com.apple.ResourceFork   32
xattr -lx testfile-hfs
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
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

ln -s testfile-hfs testlink-hfs
xattr -ws  org.home.attribute "00000000000000000000000000000000" testlink-hfs
xattr -wsx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testlink-hfs
xattr -ws  com.apple.ResourceFork "00000000000000000000000000000000" testlink-hfs
   xattr: [Errno 1] Operation not permitted: 'testlink-hfs'
ls -l@ testlink-hfs
lrwxr-xr-x@ 1 user  staff  13 20 Feb 21:56 testlink-hfs -> testfile-hfs
   com.apple.FinderInfo   32
   org.home.attribute   32
xattr -lsx testlink-hfs
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


Repeating the same steps on the same machine with the same OS on the internal APFS SSD leaves FinderInfo unchanged in both cases.

So at least in my case, the suggested mimic behaviour would make sense then.

[Arne]

Tested on ElCapitan 10.11

First the test with a file

Code: Select all

[~]$ xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile-hfs
[~]$ xattr -w  com.apple.ResourceFork "00000000000000000000000000000000" testfile-hfs
[~]$ ls -l@ testfile-hfs

-rw-r--r--@ 1 arne  staff  0 20 Feb 14:50 testfile-hfs
   com.apple.FinderInfo   32
   com.apple.ResourceFork   32

[~]$ xattr -lx testfile-hfs

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
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


Seems to be the same results as on Ventura.

Then the one with the symbolic link

Code: Select all

[~]$ ln -s testfile-hfs testlink-hfs
[~]$ xattr -ws  org.home.attribute "00000000000000000000000000000000" testlink-hfs
[~]$ xattr -wsx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testlink-hfs
[~]$ xattr -ws  com.apple.ResourceFork "00000000000000000000000000000000" testlink-hfs

xattr: [Errno 1] Operation not permitted: 'testlink-hfs'

[~]$ ls -l@ testlink-hfs

lrwxr-xr-x@ 1 arne  staff  12 20 Feb 14:56 testlink-hfs -> testfile-hfs
   com.apple.FinderInfo   32
   org.home.attribute   32

[~]$ xattr -lsx testlink-hfs

com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 31 31 31 31 31 31 31 31  |........11111111|
00000010  00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00  |........1111....|
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



Ok, there is a difference by FinderInfo.
On ElCapitan the "31" is shown as "1" whereas on Ventura it is ".".

[Arne]

Just for the fun of it I tested your commands on a zfs dataset with openzfs 1.9.4.

In contrast to hfs there is no masking of FinderInfo at all neither by the file nor by the symlink.
And the symlink can have a ResourceFork.

Code: Select all

[~/zfs]$ touch testfile-zfs
[~/zfs]$ xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile-zfs
[~/zfs]$ xattr -w  com.apple.ResourceFork "00000000000000000000000000000000" testfile-zfs
[~/zfs]$ ls -l@ testfile-zfs

-rw-r--r--@ 1 arne  staff  0 20 Feb 15:14 testfile-zfs
   com.apple.FinderInfo   32
   com.apple.ResourceFork   32

[~/zfs]$ xattr -lx testfile-zfs

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
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


Code: Select all

[~/zfs]$ ln -s testfile-zfs testlink-zfs
[~/zfs]$ xattr -ws  org.home.attribute "00000000000000000000000000000000" testlink-zfs
[~/zfs]$ xattr -wsx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testlink-zfs
[~/zfs]$ xattr -ws  com.apple.ResourceFork "00000000000000000000000000000000" testlink-zfs
[~/zfs]$ ls -l@ testlink-zfs

lrwxr-xr-x@ 1 arne  staff  12 20 Feb 15:15 testlink-zfs -> testfile-zfs
   org.home.attribute   32
   com.apple.FinderInfo   32
   com.apple.ResourceFork   32

[~/zfs]$ xattr -lsx testlink-zfs

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.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
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