Mounting a snapshot creates a broken link inside Finder's sidebar that cannot be removed

[ggrocca]

I was able to replicate this even using a file based pool. Steps to replicate:

• take a snapshot.
• Mount it (sudo zfs mount uno/fsuno@snap-20191229-2121)
• If I click on the new item in Finder's sidebar (see screenshot), an error message appears (see other screenshot).
• If I unmount the snapshot (sudo zfs unmount uno/fsuno@snap-20191229-2121), the unmount operation is successful, but the item remains stuck in the sidebar.
• Everything I tried to remove it from the sidebar (short of rebooting) does not work, not even restarting Finder. Right click and "Remove from sidebar" doesn't work, drag&dropping out of Finder doesn't work, etc.

Any Ideas? Is this bug reproducible to anyone? I tried to find a similar issue in the archive but I found nothing. My OpenZFS versione, as reported by brew cask, is: OpenZFS on OS X 1.9.3 Mojave.pkg (Pkg).

[JMoVS]

yes, snapshot mounting directly is super buggy currently. I recommend cloning the snapshot, giving the clone a sensible mountpath and mount the clone and destroy that clone afterwards.

@lundman Maybe we should make it com.apple.nobrowse so mounted snapshots don't show up in the sidebar?

[ggrocca]

@JMoVS , interesting to know (that direct mounting is buggy). Buggy how exactly? Is it safe to use or should it be ignored as a feature? I forgot to mention that access after direct mounting using the command line to the .svn/snapshots directory was working correctly AFAIK (my intention was to check some diffs to certain files, becase zfs diff was marking them as changed). [by the way, in doing it I discovered that the atime=off option seems to be broken, but I want to confirm the bug somehow and do some research before submitting another issue on this].

Using com.apple.nobrowse for this kind of automatic mountings seems a good idea to me - this kind of accesses certainly do not require GUI shortcuts, and they can be opened inside finder anyway by way of $ open /Volumes/pool/dataset/.zfs/snapshot/etcetc.

I will also mention that I'm already using com.apple.nobrowse to avoid having all datasets shown in the mac sidebar, but I find that the option doesn't work in a completely consistent way: sometimes after a reboot the datasets are there anyway and I have to manually export and import the pool again for the option to work correctly. I cannot say that the issue is reproducible though.

[lundman]

I get an entry for a mounted snapshot under "Locations" which could be appearing there just because it has an "@" in the name. Could be worth doing a quick check by changing the @ to something else (kernel devs).

As for Finder, even if you use Goto-Location, and enter /Volumes/tank/.zfs it gives an error there. It appears to perhaps be because Finder tries to do all lookups in "reverse" as well.

As in, it uses the mount id, and file id, to look up an object:

# stat /Volumes/tank
889192452 2 drwxr-xr-x 38 lundman admin 0 38 "Jan 10 11:45:34 2020" "Jan 10 11:09:26 2020" "Jan 10 11:27:33 2020" "Jan 10 11:27:24 2020" 512 5 0 /Volumes/tank

889192452 69 -rw-r--r-- 1 lundman admin 0 27687 "Jan 10 11:27:34 2020" "Jan 10 11:09:26 2020" "Jan 10 11:27:34 2020" "Jan 10 11:27:33 2020" 28160 56 0 /Volumes/tank/Makefile

So, in this case, the mount id for everything inside the volume named "tank" is 889192452 and the file id for the directory tank is 2. And Makefile has id of 69.

Which means you can look it up by id using;

# stat /.vol/889192452/69
889192452 69 -rw-r--r-- 1 lundman admin 0 27687 "Jan 10 11:27:34 2020" "Jan 10 11:09:26 2020" "Jan 10 11:27:34 2020" "Jan 10 11:27:33 2020" 28160 56 0 /.vol/889192452/69

And indeed, even ask for the name (which is where OSX differs from the other Unix variants)

# ~/FSMegaInfo getattrlist -ATTR_CMN_NAME /.vol/889192452/69
getattrlist -ATTR_CMN_NAME /.vol/889192452/69
    ATTR_CMN_NAME = 'Makefile'

The problem starts with .zfs:

# stat /Volumes/tank/.zfs
889192452 3 dr-xr-xr-x 1 root wheel 0 2 "Jan 10 11:56:08 2020" "Jan  1 09:00:00 1970" "Jan  1 09:00:00 1970" "Jan  1 09:00:00 1970" 131072 1 0 /Volumes/tank/.zfs

# stat /.vol/889192452/3
stat: /.vol/889192452/3: stat: No such file or directory

Because .zfs (and also.zfs/snapshot ) are "virtual" directories, and do not "exist", the zfs_vget() function does not know about them and return error.

We would need to extend zfs_vget() to handle .zfs (id 3), and .zfs/snapshot (id 4) and return enough fake information to please Finder.

The directory after that (in my case, snapshot hello) is its own mount, so gets a new mountid, and fileid (2, as it is root):

# stat /Volumes/tank/.zfs/snapshot/hello
889192453 2 drwxr-xr-x 38 lundman admin 0 38 "Jan 10 11:27:24 2020" "Jan 10 11:09:26 2020" "Jan 10 11:27:33 2020" "Jan 10 11:27:24 2020" 2560 5 0 /Volumes/tank/.zfs/snapshot/hello

# stat /.vol/889192453/2
889192453 2 drwxr-xr-x 38 lundman admin 0 38 "Jan 10 11:27:24 2020" "Jan 10 11:09:26 2020" "Jan 10 11:27:33 2020" "Jan 10 11:27:24 2020" 2560 5 0 /.vol/889192453/2

So everything below that works as expected.

[lundman]

76f6eed

Neat thing the snapshot mount show as regular mounted volumes as well, so you can just Finder over there. There appears to be a loop in the snapshot's ".zfs" directory pointing to itself. We may want to stop that.