Problems with xattr / v2.1.6 Monterey (Intel)

[lundman]

OK here is build with FinderInfo only being zerod if mimic=hfs.

It has the fix for uchg in it.

There is also some crypto compat attempt in it.


file deleted

viewtopic.php?f=26&t=3750&p=12137#p12137

[roemer]

I tried above's 2.1.99 package on Catalina, but it seems not to work as intended?

Code: Select all

zfs get com.apple.mimic ztank/test
NAME        PROPERTY         VALUE                SOURCE
ztank/test  com.apple.mimic  apfs                 local

touch testfile-zfs
xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile-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  00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00  |........1111....|
00000020

chflags uchg testfile-zfs
chflags: testfile-zfs: Operation not permitted

Am I on the right version - do I need a second reboot?

Code: Select all

zfs version
zfs-macOS-2.1.6-1
zfs-kmod-2.1.6-1

strings /Library/Extensions/zfs.kext/Contents/MacOS/zfs | grep -E '[0-9]\.[0-9]\.[0-9]\-'
zfs-macOS-2.1.6-0-g529f781b3
2.1.6-1

Or do I need to set zfs_xattr_compat? This is currently not set on my test system...

Code: Select all

sysctl -a | grep zfs_xattr_compat
[nothing...]


[lundman]

After loaded/rebooted it should say:

Code: Select all

# zpool version
zfs-2.1.99-1731_g1e3ae29d3
zfs-kmod-2.1.99-1731_g1e3ae29d3


[lundman]

OK previous pkg was a dud, sorry about that.

here is the proper one:

OpenZFSonOsX-2.1.99-Catalina-10.15.pkg

(16.39 MiB) Downloaded 560 times

Code: Select all

# zpool version
zfs-2.1.99-1731_g1e3ae29d3
zfs-kmod-2.1.99-1731_g1e3ae29d3


[roemer]

Many thanks @lundman, this new version works now much better!

I tried this on an Intel iMac with macOS Catalina (10.15.6).

• FinderInfo indeed not masked anymore if com.apple.mimic=apfs or com.apple.mimic=off
• FinderInfo masked if com.apple.mimic=hfs
• chflags uchg FILENAME works
• correspondingly, locking a file or folder via Finder works
• ACLs seem to work
• I can mount my encrypted dataset again which I couldn't until now (getting an 'Input/output error'; cf: viewtopic.php?t=3766)
• side note: encryption on Intel seems to include hw acceleration (kstat.zfs.darwin.tunable.icp_aes_impl: cycle [fastest] generic x86_64 aesni)

A few open issues still exist though:

• FILENAME/..namedfork/rsrc special path seems not supported yet
• I cannot set a 'archived' BSD flag
• ResourceFork xattr can be created on a symlink, though neither HFS nor APFS write a ResourceFork on a symlink
• creating an empty xattr only works if there is already any other extended attribute; if it is the first, the xattr tool fails miserably:

Code: Select all

touch testfile-zfs
xattr -w org.home.emptyattr "" testfile-zfs
  File "/usr/bin/xattr", line 13, in <module>
    load_entry_point('xattr==0.6.4', 'console_scripts', 'xattr')()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/xattr/tool.py", line 258, in main
    doSinglePathChange(filename,attr_name,attr_value,read,write,delete,recursive)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/xattr/tool.py", line 198, in doSinglePathChange
    attrs[attr_name] = attr_value
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/xattr/__init__.py", line 124, in __setitem__
    self.set(item, value)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/xattr/__init__.py", line 93, in set
    self._set(name, value, 0, options | self.options)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/xattr/__init__.py", line 28, in _func
    return func(first, *args)
   KeyError: 'org.home.emptyattr'
xattr -lx testfile-zfs
[nothing]

xattr -w org.home.someattr  "test" testfile-zfs
xattr -w org.home.emptyattr ""     testfile-zfs
ls -l@ testfile-zfs
-rw-r--r--@ 1 user  staff  0 22 Feb 20:20 testfile-zfs
   org.home.someattr   4
   org.home.emptyattr   0


[lundman]

Excellent, thanks for the feedback.

FILENAME/..namedfork/rsrc special path seems not supported yet

How are you testing this? Appears to work here:

Code: Select all

# touch /Volumes/BOOM/testfile.txt
# echo "HelloWorld" > /Volumes/BOOM/testfile.txt/..namedfork/rsrc
# cat /Volumes/BOOM/testfile.txt/..namedfork/rsrc
HelloWorld
# xattr /Volumes/BOOM/testfile.txt
com.apple.ResourceFork
# xattr -l /Volumes/BOOM/testfile.txt
com.apple.ResourceFork: HelloWorld


I cannot set a 'archived' BSD flag

That is true - it's complicated. It seems ZFS_ARCHIVE and SF_ARCHIVED work differently.
ZFS turns on ZFS_ARCHIVE automatically, and a lot. Possibly we should define SF_ARCHIVED as
a new separate field.
Is it useful? What do we use it for normally?

ResourceFork xattr can be created on a symlink, though neither HFS nor APFS write a ResourceFork on a symlink

I did not know that, ok, that's an easy fix.

creating an empty xattr only works if there is already any other extended attribute; if it is the first, the xattr tool fails miserably

Yeah it seems the xattr script is a bit crappy there. I wrote a small setter program to test it myself:

Code: Select all

# cat x.c
#include <stdio.h>
#include <sys/xattr.h>

int main(int argc, char **argv)
{
        int err;

        err = setxattr("/Volumes/BOOM/test.txt",
                "org.xattr.empty",
                "", 0,
                0,0);
        printf("setxattr %d\n", err);
}

clang -o x x.c


[lundman]

Also, how do you test the symlink vs resourcefork?

Code: Select all

# touch /tmp/roger
# ln -s /tmp/roger /tmp/moore
# xattr -w com.apple.ResourceFork HelloWorld /tmp/moore   
# xattr -l /tmp/moore   
com.apple.ResourceFork: HelloWorld


[lundman]

The sources agree with you, I'll just copy them

Code: Select all

        /* Write the Resource Fork. */
        if (strcmp(ap->a_name, XATTR_RESOURCEFORK_NAME) == 0) {
                struct vnode *rvp = NULL;
                int namelen = 0;
                int openunlinked = 0;

                if (!vnode_isreg(vp)) {
                        return (EPERM);


[roemer]

Testing FILENAME/..namedfork/rsrc, it seems to work if one writes and reads via that special path, but if you write the extended attribute directly using xattr, you cannot read it via the special path:

Code: Select all

touch testfile-rfork.txt
echo "HelloWorld" > testfile-rfork.txt/..namedfork/rsrc
ls -aleO@ testfile-rfork.txt
-rw-r--r--@ 1 user  staff  - 11 22 Feb 21:37 testfile-rfork.txt
   com.apple.ResourceFork   11
xattr -lx testfile-rfork.txt
com.apple.ResourceFork:
00000000  48 65 6C 6C 6F 57 6F 72 6C 64 0A                 |HelloWorld.|
0000000b
cat testfile-rfork.txt/..namedfork/rsrc
HelloWorld

# so far, so good; but now let's write a new value via xattr:

xattr -w com.apple.ResourceFork "Hello You" testfile-rfork.txt
xattr -lx testfile-rfork.txt
com.apple.ResourceFork:
00000000  48 65 6C 6C 6F 20 59 6F 75                       |Hello You|
00000009
cat testfile-rfork.txt/..namedfork/rsrc
cat: testfile-rfork.txt/..namedfork/rsrc: No such file or directory


To test ResourceForks on symlinks, you need the '-s' option for xattr so that it writes to the symlink itself, and not through to its target.

Code: Select all

ln -s testfile-zfs testlink-zfs
# notice the -s option:
xattr -ws  com.apple.ResourceFork "Whatever" testlink-zfs
ls -l@ testlink-zfs
lrwxr-xr-x@ 1 user  staff  13 22 Feb 18:52 testlink-zfs -> testfile-zfs
   com.apple.ResourceFork   8

About the ARCHIVE flag: I am not using it myself at all (as far as I am aware, you never know what some applicatrions try to do).
It just failed in my test cases that simply tried out all BSD flags on file, dir and symlinks.
But I agree, this is not the most urgent thing to fix.

The ..namedFork path above appears to be more important because I cannot set a custom icon on a folder of file via Finder. I do not know why, but the icon is not correctly displayed when set on a folder, and it simply does not work when tried on a file.

I also tried to sync files with ResourceForks using rsync. Rsync seems to write them as extended attributes - and then I can't read the resource fork of the synced copy via the special path, while I could do so on the source file before the rsync.

[lundman]

Ah "xattr -s". OK, checks out now