Getting volume of Posix path when volume names collide

I need to find out what disk a posix path points to. Normally, that’s simple: just get the posix path and split on “/” and take the item after “Volumes”.
However, consider this scenario:
a user has two disk images: one 2mb large and another 5mb large, named “Small Backup.dmg” and “Large Backup.dmg” respectively. However, both mounted volumes are named “Backup Disk”.
If the user mounts both, the path to one is “/Volumes/Backup Disk” and the other is “/Volumes/Backup Disk 1”.

How can I convert the posix path in such a way into a Finder disk object so that I can get it’s capacity? I can just use “df” in the shell, but I’m curious if there’s a way of doing this coercion.


Hi Conrad,

Perhaps this information supplied by the Finder will help you:

tell application "Finder" to get properties of disks

or perhaps:

tell application "Finder" to get {name, URL, size} of disks

Best wishes

John M

set posixPath to "/Volumes/MacHD"
set theAlias to POSIX file posixPath as alias -- note: Finder doesn't like POSIX file objects so give it an alias object instead
tell application "Finder" to get item theAlias
--> disk "MacHD" of application "Finder"

Thank you all for your help! Hhas, your solution is spot-on as always. Much appreciated.

Follow up question:
if I get a list of disks from the finder, in the same situation with collisions, how do I get the POSIX path to each disk?

tell application "Finder" to set diskList to (get disks whose local volume = true and ejectable = true)
repeat with aDisk in diskList
	tell application "Finder" to set diskPath to POSIX path of (aDisk as alias)
end repeat

In the previous scenario, diskPath with end up with “/Volumes/Backup Disk” twice, and never show “/Volumes/Backup Disk 1”


That would be a bug (surprise!) in the ‘POSIX path’ property of AppleScript’s alias objects. Feel free to file a bug report on it with Apple.

Meantime, here’s a workaround:

on urlToPOSIXPath(theURL)
	return do shell script "python -c 'import urllib, urlparse, sys; print urllib.unquote(urlparse.urlparse(sys.argv[1])[2])' " & quoted form of theURL
end urlToPOSIXPath

tell application "Finder" to set diskList to url of every disk whose local volume = true and ejectable = true
repeat with urlRef in diskList
	set urlRef's contents to urlToPOSIXPath(urlRef's contents)
end repeat
return diskList --> {"/", "/Volumes/MacHD/", "/Volumes/MacHD 1/"}


Thanks again Hamish! I filed the bug. I really appreciate the help.
all the best,

A couple further observations, posted here for completeness…

I notice that:

POSIX path of (theAlias as «class furl»)

will also return a POSIX path with the correct disk name, assuming the alias object itself is pointing at the right drive. e.g. Bear in mind that Finder has its own problems producing reliable Finder references to different disks with the same name. So you can’t, for example, get a reliable alias from Finder if all you’ve got is an unreliable Finder reference:

tell application "Finder"
	set diskList to every disk whose local volume = true and ejectable = true
	repeat with finderRef in diskList
		set finderRef's contents to POSIX path of (finderRef as alias as «class furl») -- Alas, the Finder disk reference in finderRef is already a lost cause.
	end repeat
end tell
return diskList
--> {"/", "/Volumes/Foo/", "/Volumes/Foo/"} -- Borked again! :(

Compare with this example, where the alias objects are obtained straight from the horse’s mouth:

tell application "Finder"
	set diskList to (every disk whose local volume = true and ejectable = true) as alias list
end tell
repeat with aliasRef in diskList
	set aliasRef's contents to POSIX path of (aliasRef as «class furl»)
end repeat
return diskList
--> {"/", "/Volumes/MacHD/", "/Volumes/Audio CD/", "/Volumes/MacHD 1/"} -- OK

However, the ‘as alias list’ coercion is buggy and will fail when there’s only one item, so don’t bother using this approach as it’s effectively useless. Stick with the URL-based solution I showed originally; I’m fairly sure neither Finder nor AppleScript can screw that one up. :slight_smile:

Alternatively, move to Perl/Python/Tcl/etc. ;p

Thanks again Hamish! Thorough and incredibly informative as always! Much obliged!