cannot eject after a (very simple) script runs.

hi everyone,

the problem i’m having is actually in an AS studio app, but the issue i’ve encountered trying to solve it seems to be a general AS one, therefore, i believe, it belong here.

a small part of the app has the simple function of ejecting volumes dragged to it, however the “drop” handler in ASS return posix paths which need to be converted, before i can tell the finder to eject.
the process is really simple: repeat through the items → convert posix to file reference → determine if item is a volume → eject if it is.
however when i try to run it the disk would not be eject, on account of it being in use. ( it wasn’t before the the app ran).
this made me think that somewhere in this process the disk somehow “gets used”, i managed to narrow the problem down, and came up with this weird thing:

i’ve written this short script…

set anitem to "/Volumes/works" -- originally set in a repeat loop through the dropped items.

tell application "Finder"
	kind of (info for (anitem as POSIX file)) is "Volume" --> true
end tell

which does nothing but returning “true”. but after i run it, (exactly as it is written here), i can’t eject the disk “works” in any way but force.
i’ve tried it a million times: i mount the disk → unmount it (drag it to the trash, press eject, etc.) → no problem. i mount the disk → run the script → the disk wouldn’t unmount until i force it. i’ve also tried the script with different disks, just to be sure, same thing.

does it work like that for anybody else? or is it my system?

i realize that i can get around that by avoiding the conversion from posix to file reference ( which seems to be causing the problem), determine somehow if the item is a volume (i haven’t figured out how to do that without the finder yet…) , and use the shell for ejecting.
but there has to be a way to make it work like this.

any ideas?


Would this get the job done?

set the VolumeToEject to ""

set the disks_mounted to list disks
if the disks_mounted contains the VolumeToEject then
	tell application "Finder"
			eject disk the VolumeToEject
			set the disks_mounted to list disks
			if the disks_mounted does not contain the VolumeToEject then exit repeat
			delay 1
		end repeat
	end tell
end if

Some ideas:
-You don’t need the Finder block, as “info for” is part of the Standard Additions osax.
-“kind” is a localized string, so it won’t work in my machine, as volumes are called “Volumen” instead of “Volume” (not a problem if you won’t distribute your script to other machines, though).

I think there are lots of ways, but I can’t test if your code causes or not such behaviours in my machine, so I’ll throw some code ideas:

set x to "/Volumes/CD de audio"

	set x to POSIX file x as alias as text --> ie, "CD de audio:"
	set AppleScript's text item delimiters to ":"
	set x to x's text items
	set AppleScript's text item delimiters to {""}
	--> check for more-than-one-colon
	if (count x) is 2 then
		display dialog "is volume!" with icon 1 buttons {"OK"} default button 1
		display dialog "is not volume!" with icon 1 buttons {"OK"} default button 1
	end if
on error --> hi-unicode in path
	set parentDir to (do shell script "dirname " & quoted form of x)
	set o to "not "
	if parentDir is "/Volumes" then
		set itemName to (do shell script "basename " & quoted form of x)
		if itemName is in (list disks) then set o to ""
	end if
	display dialog "is " & o & "volume!" with icon 1 buttons {"OK"} default button 1
end try

A different approach (perhaps more interesting) would be something as (pseudo-code):

	tell application "Finder" to eject WhatEver
on error
	--> was not a volume
end try

After several restarts, I think ‘info for’ must have some bug that prevents it letting go of volumes it quizzes. Since you’re using the Finder to eject the volumes, you could use it to test for them too:

set anitem to "/Volumes/works" -- originally set in a repeat loop through the dropped items.

if (anitem begins with "/Volumes/") then
	tell application "Finder"
		tell item (anitem as POSIX file as Unicode text) -- This line corrected in the edit.
			if (its class is disk) then eject
		end tell
	end tell
end if

Hi Nigel,

Is it just for the new ‘kind’ property return from ‘info for’ or for any property.

Edited: disregard. It couldn’t be just for the ‘kind’ proprety.


Hi, kel.

I only tested it in Tiger. Just the act of using ‘info for’ on a (network) volume ” with or without the Finder ‘tell’ block ” prevented me from subsequently ejecting that volume. The only way out that I could find was to restart the machine that had run the script.

Hi Nigel,

I was thinking that there might be a bug with ‘info for’ in Tiger, because there isn’t the ‘kind’ property here in Jaguar and info for disk doesn’t effect the disk.

So, if the posix path begins with “/Volumes/”, then we know it’s a disk, right? We might want to check if it’s ejectable though.


Hi, kel.

We know that a disk is involved, but not whether it is a disk on an item on one ” I think. :slight_smile: I must admit I haven’t looked very closely into ejectability and stuff in the current context.

Hi Nigel,

I wasn’t sure either, so I ran my test drop AS Studio project. Only disks begin with volumes, so you’ve found a fast way for noiroi to find out if it’s a volume without using the info for or Finder. disks like the startup disk aren’t ejectable and might throw an error, so something like this:

set u_path to “/Volumes/TestImage”
set as_ref to (u_path as POSIX file) as alias
tell application “Finder”
if ejectable of as_ref then eject as_ref
end tell

I don’t know if getting ejectable of the disk would have the same bug as the ‘info for’ command in Tiger.



I ran my test studio project and dropped the startup disk. It ruturned “/”, so I guess you don’t need to check for ejectable.


Hi, kel.

  1. I think you’re probably right.
  2. It seems to be just as well. When my Jaguar and Tiger machines are networked together, the ‘ejectable’ of theTiger one’s hard disk is ‘true’ as seen from the Jaguar machine, but those of the Jaguar one’s hard disk and external disks are ‘false’ as seen from the Tiger machine. However, there’s no problem ejecting any of them manually or by script. :\
  3. I’ve just noticed the typo in the script I posted earlier, which I’ve now corrected.