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: Christopher Nebel <email@hidden>
- Date: Fri, 23 Apr 2004 18:58:36 -0700
On Apr 11, 2004, at 10:08 AM, Graff wrote:
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?
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.
Unlikely. This problem shows up with diskutil because it's more or
less impossible to eject a disk synchronously on Mac OS X -- this sort
of situation is quite rare. In general, sub-tasks are run in a
reasonably predictable manner, and "do shell script" will return when
they are all done and not before.
--Chris Nebel
AppleScript Engineering
_______________________________________________
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.