Force ejecting doesn't remove volume from finder

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Take HelloFS example and insert usleep() in it's "read" implementation
2. Open mounted volume in finder and wait for macfuse's message
3. Press "Force eject" button
4. See volume is still present in finder

What version of the product are you using? On what operating system?
MacFUSE 0.4.0
MacOS X 10.4.9

Is it possible to kill daemon on force ejecting?

Original issue reported on code.google.com by vasily.z...@gmail.com on 22 Jun 2007 at 2:56

[GoogleCodeExporter]

> Is it possible to kill daemon on force ejecting?

Yes, but even killing the daemon might not make the icon go away from the 
Finder's standpoint. You can use the 
kill_on_unmount option to try that.

In some cases, the Finder will refuse to let go of the icon. It's still a much 
better situation because things 
shouldn't hang or anything--just dragging the icon to the trash or cmd-E should 
get rid of the icon. There's 
only so much that can be done without *being* the Finder itself.

Original comment by si...@gmail.com on 22 Jun 2007 at 6:05

[GoogleCodeExporter]

kill_on_unmount doesn't kill my daemon on force ejecting.
Icon disappears from finder when i run "umount -f /my/mountpoint" from terminal 
after
force ejecting. After that daemon dies too.

Original comment by vasily.z...@gmail.com on 22 Jun 2007 at 7:25

[GoogleCodeExporter]

The kernel itself can't "unmount" something from within itself--the best it can 
do is to make the file system 
"dead", let the Finder know, and send a signal to your daemon. Depending on 
what exactly is going on (the 
daemon might be in an uninterruptible call in the kernel), one or more of these 
measures may not be able to 
have the desired effect. The goal really is to prevent a deadlock that can't be 
broken. If you *can* do "umount 
-f" and things don't hang, that goal is being met. The other nice-to-have 
things (like the eject going all the 
way through to the Finder and the icon disappearing)--that will work in some 
cases but not in others.

The behavior you are seeing--if you simply suspend (ctrl-z or sigstop) the 
daemon, you'll probably have a 
similar situation. Again, you should be able to avoid a deadlock, but the 
Finder icon may not go away by 
itself.

If, some day, it becomes possible to make the Finder happy in all situations, 
I'll do that.

Original comment by si...@gmail.com on 22 Jun 2007 at 7:36

[GoogleCodeExporter]

Please, is this similar to 
MacFusion issue_6 
<http://code.google.com/p/macfusion/issues/detail?id=6>?

Original comment by grahampe...@gmail.com on 1 Jul 2007 at 1:49

[GoogleCodeExporter]

grahamperrin, yes, it does look like the same issue.

What *is* guaranteed when the user clicks on "Force Eject" is that a "file 
system is dead" notification will be sent 
system wide. In most cases, the Finder should be able to unmount the volume 
"properly" (icon disappearing and 
all) based on this notification. It wouldn't hurt for MacFusion to also listen 
for this notification, and when it gets 
it, issue a "umount -f" type of action, which should cover the cases when the 
icon persists on the Desktop 
(essentially what you have is a "dead" mount left behind).

Original comment by si...@gmail.com on 2 Jul 2007 at 6:33

[GoogleCodeExporter]

Amit, thanks. I have cross referenced to this issue so that Michael may note 
your advice.

Original comment by grahampe...@gmail.com on 2 Jul 2007 at 12:01

[GoogleCodeExporter]

> What *is* guaranteed when the user clicks on "Force Eject" is that a "file 
system
is > dead" notification will be sent system wide.

Could you please send me (or attach to this post) the sample code how to handle 
this
notification.

Original comment by vasily.z...@gmail.com on 2 Jul 2007 at 1:06

[GoogleCodeExporter]

Simple. Thanks for your advice Amit.

Original comment by mgorb...@gmail.com on 2 Jul 2007 at 9:13

[GoogleCodeExporter]

In case I wasn't clear enough: it's the VQ_* vfs notifications I'm talking 
about. I don't remember if some/all of 
these are also available through any standard notification center, but you can 
use kqueue()/kevent() to listen for 
them. The book "Mac OS X Internals" has an example program (Figure 12-33) that 
does this. If you don't have 
access to the book, look for the relevant source online.

Original comment by si...@gmail.com on 13 Jul 2007 at 12:09

• Changed state: WontFix

[GoogleCodeExporter]

Thanks. I listen for VQ_DEAD notification with kqueue()/kevent() in external
application. I have several fs daemons running. Is it possible to determine from
which fs I receive a notification? I initialize kevent struct as EV_SET(&kev, 0,
EVFILT_FS, EV_ADD | EV_ENABLE | EV_CLEAR, VQ_DEAD, 0, 0). Or how can I check 
for fs
is dead, if I know mountpoints?

Original comment by vasily.z...@gmail.com on 16 Jul 2007 at 8:53