Cannot access some datasets with Finder
sam81 opened this issue · comments
I'm experiencing an issue which seems similar to the one described in #112. I have a pool with several datasets, I can access all of them through the terminal without issues, but in Finder weird issues occur for some datasets. For example one of the datasets is called "work", and has a subfolder called "auditory". When I open the datasets sometimes I get a disk icon with "work", and sometimes I get a folder icon with "auditory", but even in the latter case I can't access the folders inside the "auditory" folder. When I click on it I get again an icon with "auditory", and clicking a few times I get back to the "work" icon with the disk folder. There's some kind of weird recursion going on. This is what I get when I expand the contents in the details view:
The datasets that are working and those that are not working have exactly the same zfs properties. I tried setting com.apple.devdisk=on, a workaround mentioned for issue #112, for the problematic datasets but that didn't change the issue.
This is occurring with OpenZFS on OSX v1.9.2 on MacOS High Sierra.
On issue #112 it is mentioned that Finder gets confused when several datasets exist with the same final name component. That may be the case here, the datasets in the pool where the issue is occurring have many subdirectories, and it may be the case that some directory paths end with the same name, they're large datasets, so it's not possible to check this manually.
The other OSX specific ZFS properties are set as follows:
com.apple.browse on default
com.apple.ignoreowner off default
com.apple.mimic_hfs off default
this looks like a recent forum thread where I think @lundman replied - is this still open?
I had posted the issue here https://openzfsonosx.org/forum/viewtopic.php?f=26&t=3263 before opening the issue on github, but didn't get a reply (@lundman had replied to a previous post in the same thread). As I mentioned the issue I opened looks similar to #112 , which is a closed issue, but the workaround mentioned there, setting com.apple.devdisk=on doesn't work, so I'd say the issue is still open.
That looks more like the findericon problem, mentioned here: https://openzfsonosx.org/forum/viewtopic.php?f=26&t=3299&start=10#p9645
You could test it by creating a ".VolumeIcon.icns" directory on the Linux side, so it already exists when you send it over - this stops the faulty icon code from triggering when mounting.
thanks, I tried deleting the ".VolumeIcon.icns" file and creating a ".VolumeIcon.icns" folder on linux. When I mount the pool on MacOS now I don't get the funny recursion issue BUT I still can't access the subdirectories in the problematic datasets in Finder (I'm only able to go one subdirectory below the parent directory in Finder, I can't access the directories below that). This happens with both com.apple.devdisk set to poolonly (the default), or set to on.
Ok so you confirm the VolumeIcon is also an issue for you.
Then separately, there is an issue using Finder to descend into directories more than one deep? What are the symptoms? sub-directories don't show? Greyed out? And we are talking about regular directories, not datasets mounted lower?
these are regular directories, they simply don't show (also the first subfolder, which shows, appears as a white blank icon now).
My pool has four datasets. The issue occurs only on one of them. I just realized something: the first few subfolders in the problematic dataset, which is called 'work' are:
work/auditory/exp/...and so on
the first few subfolder in another dataset of the same pool called 'lin_home' are:
lin_home/auditory/code/...and so on
I created other subfolders in the 'work' datasets ('work/jlk/tyu/') and I can access those in Finder. So the problem may be that the first subfolder in the 'work' dataset has exactly the same name as the first subfolder in the 'lin_home' dataset (which I think is issue #112)
Ah right, that frustrating thing - yes Finder is picky about that. I actually thought we had solved that, but appears not to be the case.
A couple more observations:
- I renamed the 'auditory' directory in the 'work' dataset with a completely different name (did this on linux), but the subfolders below it still remain inaccessible in Finder with MacOS, so maybe the problem is not with the directory name after all (or is zfs on MacOS somehow keeping track and having issues with that directory despite the name change?)?
- I created another directory tree in the work dataset in linux, and I can access that path fine in Finder with MacOS, so the issue does not seem generally related to directories created on linux
Anything different about the permissions on the dir? permissions, or acls?
I'm pasting the output of 'ls -l' on the 'work' directory:
sam@Mac-Pro-di-Samuele - /extdrive/work $ ls -l
total 19
drwxrwsr-x 3 sam extdrive 3 8 Ott 12:37 fornitra
drwxr-sr-x 3 sam extdrive 3 8 Ott 03:07 klj
drwxrwsr-x 6 sam extdrive 6 28 Mar 2019 palamk
the 'palamk' directory is the problematic one (the one which used to be called 'auditory'), the 'fornitra' directory was created on linux and I can access it fine, the 'klj' directory was created on the Mac and I can access it fine. How do I check acls?
ls -le@
-e for acl, and -@ for xattr.
thanks, the output looks the same:
sam@Mac-Pro-di-Samuele - /extdrive/work $ ls -le@
total 19
drwxrwsr-x 3 sam extdrive 3 8 Ott 12:37 fornitra
drwxr-sr-x 3 sam extdrive 3 8 Ott 03:07 klj
drwxrwsr-x 6 sam extdrive 6 28 Mar 2019 palamk
can you run stat fornitra klj palamk ?
this is the output:
sam@Mac-Pro-di-Samuele - /extdrive/work $ stat fornitra klj palamk
805306375 327683 drwxrwsr-x 3 sam extdrive 0 3 "Oct 8 13:05:33 2019" "Oct 8 12:37:32 2019" "Oct 8 12:37:32 2019" "Oct 8 12:37:25 2019" 512 1 0 fornitra
805306375 327704 drwxr-sr-x 3 sam extdrive 0 3 "Oct 8 13:05:18 2019" "Oct 8 03:07:40 2019" "Oct 8 03:07:40 2019" "Oct 8 03:07:33 2019" 512 1 0 klj
805306375 3 drwxrwsr-x 6 sam extdrive 0 6 "Oct 8 12:59:22 2019" "Mar 28 00:26:33 2019" "Oct 8 12:37:06 2019" "Apr 8 00:48:45 2019" 512 17 0 palamk
Ahh that is telling, palamk has ID "3". That is the problem one yes?
yes that's the one, what does the ID mean?
All elements in ZFS, dirs and files etc, all have a unique ID to identify them. In particular:
include//sys/zfs_ctldir.h:#define ZFSCTL_INO_ROOT 0x3
include//sys/zfs_ctldir.h:#define ZFSCTL_INO_SNAPDIR 0x4
include//sys/zfs_ctldir.h:#define ZFSCTL_INO_SHARES 0x5
which means "3" is reserved, so it has the same ID as root. I honestly thought all ZFS platforms reserved "3". If you re-create the dir it will work. Meanwhile, I will try to find out how it can happen.
thanks! I'll give it a go