How does 'eject' get processes to close file handles?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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.
process osx devices file-descriptors eject
add a comment |Â
up vote
2
down vote
favorite
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.
process osx devices file-descriptors eject
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 6 '17 at 8: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 6 '17 at 10:30
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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.
process osx devices file-descriptors eject
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.
process osx devices file-descriptors eject
asked Dec 6 '17 at 5:51
Harv
3271311
3271311
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 6 '17 at 8: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 6 '17 at 10:30
add a comment |Â
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 6 '17 at 8: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 6 '17 at 10:30
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 6 '17 at 8:46
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 6 '17 at 8: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 6 '17 at 10:30
@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 6 '17 at 10:30
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
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, "mlatun" ) 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
Hexx20Fi 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.
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
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, "mlatun" ) 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
Hexx20Fi 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.
add a comment |Â
up vote
0
down vote
accepted
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, "mlatun" ) 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
Hexx20Fi 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.
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
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, "mlatun" ) 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
Hexx20Fi 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.
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, "mlatun" ) 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
Hexx20Fi 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.
answered Dec 6 '17 at 17:02
thrig
22.5k12852
22.5k12852
add a comment |Â
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Dec 6 '17 at 16:58
Giacomo Catenazzi
1,973314
1,973314
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f409107%2fhow-does-eject-get-processes-to-close-file-handles%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 6 '17 at 8: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 6 '17 at 10:30