Finder.app gets confused when multiple datasets exist with the same short name

[dch]

I mentioned this on IRC, and think I nailed it down. Imagine we have:

zpool tank
tank/src/freebsd
        /osx
    /vms/freebsd
        /osx

Then OSX will display e.g. on Desktop, or in Finder's left hand sidebar, all 4 volumes aka zfs datasets even though the short names are identical.

Since the last 10.9.1 Mavericks update (I think), if 2 datasets exist with the same short name (volume name) Finder gets very confused, including:

• files in the directory are displayed with the name of the dataset, not the actual file
• clicking on the dataset becomes an infinite recursion
• flashing quickly, alternating between the correct name and the parent dataset name

This also seemed to break itunes for me, even though itunes itself didn't have duplicate names, itunes would fail to start at all, giving the itunes application could not be opened an unknown error occurred 13014.

I might be wrong, but this should be easy enough to duplicate. Since removing all duplicate volume names, this issue has disappeared completely at least for today.

[ilovezfs]

Is this still true post commit 0c3631c?

[dch]

No, the bug has shifted slightly.

creating N datasets with the same final name component results in only 1 of them being visible in Finder in the volume list, from what I see here there's no special order or selection evident in which one is visible.

[ilovezfs]

Yes we figured out the problem. Our f_mntfromname is not a real /dev entry. Instead of using /dev/disk##, we use the full name of the dataset (pool/foo). So when you type "mount" it will say that pool/foo is mounted at /pool/foo. This is what every platform does.

However, OS X expects to be able to take the basename of the f_mntfromname and have that be unique, which is not the case since we can have datasets with the same name. We are going to need unique /dev entries for each dataset, preferably ones created automatically by IOKit in the form /dev/disk##.

Although this will be a significant deviation from upstream, it will probably resolve our Spotlight-doesn't-work-at-all issue as well #84, because we will be able to use diskarbitration to mount every dataset.

[ilovezfs]

@dch and anyone else expecting this to be fixed, since it is a pretty significant enhancement request to add IOKit dev entries for every file system, I recommend using unique dataset names across the board until further notice.

We might be able to resolve this with a hack sooner, but that would be double effort. For example, we could set the f_mntfromname to be pool/foo-GUID where GUID is some GUID for the dataset, and then re-parse that in the kernel to remove the -GUID to recover the dataset name pool/foo. Unfortunately, there are a few places in the code that rely on the f_mntfromname being the dataset's full name (pool/foo), so we will need to modify that code as well, possibly factoring it out into the SPL and calling some wrapper around f_mntfromname.

[ilovezfs]

We should check if this is actually caused by the same f_mntfromname-needs-to-have-unique-basename issue: #72

[rottegift]

Where two or more datasets have the same last part (e.g. pool/data/set/lastpart and pool/data/somethingelse/lastpart), things get confused. In particular, unmounts don't happen correctly (with the side effect that zfs rename of a mounted dataset won't work).

[JMoVS]

fully resolved by issue166_lite being merged - set com.apple.devdisk=on for the datasets in question or the whole pool