How does 'eject' get processes to close file handles?

Question

On my Mac, when I 'eject' a network-mounted share, my Mac presents me with the following message, and attempts to get processes to close open file handles and cleanly dismount the share. My question is, how exactly does it accomplish that? I suppose it enumerates file handles open with my share's path, and then sends some kind of signal to the processes that own those file handles? Just a guess, please fill me in, I'm very curious about it. I thought about asking this over on the Apple stack exchange, but I'm guessing this is actually a more generally-applicable UNIX question. If I'm wrong and macOS has a special/new way of doing this and this question needs to be closed and re-opened there, just let me know.

EDIT: added screenshot.

I wonder if it does get _any_ process to close their filehandles, or if it just means those filehandles will return errors when trying to use them? — Kusalananda, Dec 06 '17 at 08:46
@Kusalananda I believe it does, because often it sits there "trying to eject" for a while, succeeds, and the volume dismounts. If I run lsof while it's doing that, I can see all the processes and files that are open that it must have to close before dismounting cleanly. — Harv, Dec 06 '17 at 10:30

score 0 · Answer 1 · answered Dec 06 '17 at 16:58

It doesn't. It just umount the filesystem, so when a program try to access again the filesystem, it will have an error (and hopefully it will try to resolve things smoothly).

Not very different with the case you detach physically a external disk (or USB pen). The filesystem is no more available, but the programs will see it just after first use.

score 0 · Accepted Answer · answered Dec 06 '17 at 17:02

I don't know but with a random USB stick and a program

$ df | grep Vol
/dev/disk1s2  12228  20  12208  1%  512  0  100%   /Volumes/Firmware
$ perl -E 'say $$; chdir "/Volumes/Firmware" or die "nope $!"; sleep 9999'
66433

We can indeed stall the eject, but before that we need some debugging of the process, here provided by DTrace run in some other terminal

$ sudo dtruss -p 66433
...

And then via what in English is called the force eject button, a few clicks and delays and warnings later the test program is still running, and the usb stick unmounted, and dtruss hasn't shown anything:

...
^C
$ lsof -p 66433 | grep cwd
perl5.26 66433 jhqdoe  cwd        cwd|rtd info error: No such file or directory
$

So for at least a standard unix program, nothing happened besides the mount point being removed out from under it. Next we can test writing something to the mount point, again with a standard unix program

$ cat writeslow
#!/usr/bin/env perl
use 5.14.0;
use warnings;

open( my $fh, ">", "/Volumes/Firmware/mlatu" ) or die "nope $!";
while (1) {
    syswrite( $fh, "mlatu\n" ) or warn "hmm $!";
    sleep 3;
}
$ perl writeslow

and elsewhere we confirm the cats are showing up (buffering may be a problem if you use some higher-level write function)

$ cat /Volumes/Firmware/mlatu
mlatu
mlatu
$

and again we force eject, and the program does notice this (but keeps on running, because it was written that way):

$ perl writeslow
hmm Input/output error at writeslow line 7.
hmm Input/output error at writeslow line 7.

so Mac OS X 10.11 (for this hardware is rather too old to run macOS) does nothing to "attempt to get processes to close open file handles" as claimed in the question, and there's no evidence "some kind of signal [is sent] to the processes that own those file handles" happens; instead the process keeps on running and if it does any sort of error checking then maybe it will fail, depending on how it was written.

At least for standard unix programs that have the standard unix cwd and use standard I/O calls; maybe Apple frameworked programs are somehow different? Let's remount the usb stick yet again and open the mlatu file with Hex Fiend.app...

$ open -a Hex\ Fiend /Volumes/Firmware/mlatu
$ lsof | grep mlatu
Hex\x20Fi 66642 jhqdoe  8r  REG  1,5  216  7 /Volumes/Firmware/mlatu
$

(or instead use TextEdit or something if you don't have Hex Fiend installed) and once again do the force eject dance...

$ screencapture -w error.png
$

and now we get a different message than for standard unix programs and no option to force unmount.

How does 'eject' get processes to close file handles?

2 Answers2