After using the fskit framework to mount thecloud disk, it does not display on the Finder sidebar

I developed a cloud drive using fskit, but after mounting it, it did not appear in the Finder sidebar and

How did you mount the volume? Whether or not a volume appears in the Finder is controlled by a mount flag ("nobrowse"), so the right/wrong mount command will cause exactly what you're describing.

the disk tool could not list it.

I'm not sure what you mean by this. What kind of volume is this and what tool/app are you referring to here?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Use this command：mount -t my_ngpc ngpc://login ~/my_ngpc

I am using my self-developed FSKit plugin, and the code has been provided in the email

Use the following command 你说 mount | grep my_ngpc

ngpc://login on /Users/li/my_mnt (my_ngpc, noowners, noatime, fskit, mounted by li)

li@lideMacBook-Pro ~ % diskutil list | grep NGPC

li@lideMacBook-Pro ~ % diskutil list | grep ngpc

li@lideMacBook-Pro ~ % diskutil list | grep my_ngpc

Use this command: mount -t my_ngpc ngpc://login ~/my_ngpc

Interesting. The part that makes this strange is that having the volume appear in the sidebar is actually the default behavior, which you normally DISABLE by passing the "nobrowse" option into mount. A few things:

1. Please file a bug on this and post the bug number back here. Even if the behavior is expected, at a minimum it would probably be worth better documenting.

2. I'd also appreciate you filing a separate bug asking for a high-level (it would probably end up in DiskArb) mount API that supports FSKit. The underlying issue here is that the lack of a high-level API means that you're not properly integrated into the system "full" volume architecture, which means the system isn't necessarily "designed" to pick up your mount. This is something we're obviously already aware of, but developer bugs help us prioritize work.

3. What does the mount entry for your volume show when run "mount" to list all current mounts? This will between the kernel mark the volume "nobrowse" and the higher-level system altering its behavior.

Finally, related to that last point, I'd recommend trying some other mount target directories. In particular, I'd make sure to test:

1. A directory entirely outside the home directory hierarchy.

2. A directory inside the home directory but outside the visible space (for example, ~/Library/Application Support/).

I haven't investigated this in detail, but I wouldn't be surprised if the Finder has some heuristics in place to try and ensure that file system navigation experience appears logically "sane" by trying to avoid presenting multiple paths into the same volume. You can see the inverse of that in the fact that "/Volumes/" isn't part of the Finder's navigable hierarchy. That is, you can "jump" to it directly using "Go-> Go To Folder...", but you can't get to it by "clicking around" within the file system.

Note that #2 is where I'd expect browsable volumes "should" mount unless/until the system provides a designated location for them (which it would manage like DiskArb does).

I am using my self-developed FSKit plugin, and the code has been provided in the email.

I've looked over your code and don't see any obvious issue from that side. However, that's basically what I'd expected as browse state isn't really something the volume driver itself should generally be aware of or control.

Following up on this, as I didn’t see it until after I’d written everything above:

Use the following command 你说 mount | grep my_ngpc ngpc://login on /Users/li/my_mnt (my_ngpc, noowners, noatime, fskit, mounted by li)

OK. This means the mount itself isn't marked "nobrowse", which means the issue is likely the Finder's heuristics. Try different mount locations and see if that helps.

Finally, this is expected behavior for your particular volume type:

li@lideMacBook-Pro ~ % diskutil list | grep NGPC li@lideMacBook-Pro ~ % diskutil list | grep ngpc li@lideMacBook-Pro ~ % diskutil list | grep my_ngpc

"diskutil" doesn't manage "volumes" it manages "disks", which then happen to have volumes on top of them. Your file system isn't listed because you're not backed by a physical device (/dev/disk#), which means diskutil can't actually "do" anything to your volume. More fundamentally, it can't really even find/track them, because diskutil actually tracks volumes from the physical device "up" (through IOKit and the BSD dev node), not from the high level volume "down". This is why a zero'ed hard drive still shows up in- it's looking for the lowest level block device, then working its way "up" to display the contents of the disk.

On the FSKit side, this is why FSManageableResourceMaintenanceOperations requires FSBlockDeviceResource- without an underlying block device, diskutil isn't aware of your volume or able to interact with it. This is also why network volume (like smb or afp) don't show up in diskutil.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware