Re: how to eject a firewire drive natively
Re: how to eject a firewire drive natively
- Subject: Re: how to eject a firewire drive natively
- From: Graff <email@hidden>
- Date: Sun, 11 Apr 2004 13:08:31 -0400
On Apr 11, 2004, at 12:32 PM, Axel Luttgens wrote:
Paul Berkowitz wrote:
Then again, it may be due to the result that AppleScript returns not
being
in the correct stream. That's quite likely since you say that
do shell script "diskutil eject " & posixPath & "> /dev/null 2>&1
&"
ending in "> /dev/null 2>&1 &" is what works.
Above holds when the command you're trying really needs to be executed
in a daemon mode or, at least, in a detached fashion.
The question here is: why damn should "disk util eject
/Volumes/volname"
need to be executed in the background while executed from a "do shell
script" command?
Just to make that point clear, this one "works":
do shell script "diskutil eject /Volumes/volname; echo hello"
even if it doesn't truly eject the volume. One gets "hello" on stdout,
command "diskutil" gets terminated from a "do shell script" point of
view.
[...]
While calling "diskutil", it seems that this one calls
"DiskManagementTool" in turn.
Once terminated, "DiskManagementTool" quits and so "diskutil" does too.
Now, when called from "do shell script", it seems that "umount" gets
called too, but afterwards, when "diskutil" has already left.
On the other hand, when executed from the shell, I couldn't observe
such
a call to "umount".
That's an interesting thing to try. Since the output stream is
obviously working correctly when you get to the echo command it just
proves to me that the problem isn't in the way the output stream is
directed. Instead the problem somehow has to do directly with the way
the diskutil process is being executed. Somehow it exhibits odd
behavior when it is attached to an AppleScript but when you detach it
completely by backgrounding it then it executes correctly.
Perhaps, as you mentioned, diskutil attempts to execute other shell
tools and they fail to run properly because of the odd context in which
they are being executed. Thus one or more of them fails and the disk
doesn't get completely ejected. This could have serious consequences
since how are you to know when this issue would show up again? Any
tool that you use from a "do shell script" command could potentially
run any number of other tools to do its job and this could show
similar, or possibly worse, behavior than we are currently seeing with
diskutil.
- Ken
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.