Sys Events ejectable property -- bug?

AppleScript
#1

I just noticed today that these two commands produce different results on my 10.11.6 machine, where I have several external USBs plugged in:

tell application "System Events"
	set sysEventsList to name of every disk whose ejectable is true
end tell

tell application "Finder"
	set finderList to name of every disk whose ejectable is true
end tell

Finder reports correctly, but System Events seems to think that all except one of my externally mounted volumes aren’t ejectable. e.g., this is what System Events says about the USB3 drive I use for Carbon Copy Cloner backups (the drive is not busy at this time):

Screen Shot 2017-06-28 at 17.22.47.png988×818 124 KB

Is this a known issue, or is there some peculiar-to-System-Events reason why it should report this differently from Finder?

#2

I suspect this is the underlying answer:

Whew…

1 Like
#3

Hmm, OK, but I’m not sure Apple Engineering’s “works as intended” response should apply to System Events.

If this makes sense for the Finder:

The fact that Finder is displaying the eject icon is based on NSURLVolumeIsInternalKey being false (the drive is external), not due to NSURLVolumeIsRemovableKey or NSURLVolumeIsEjectableKey.

I don’t see why it shouldn’t also make sense for System Events (and Image Events), since all three have the same description in their dictionaries:

Can the media be ejected (floppies, CD’s, and so on)?

The only practical difference I can see is that Finder has an eject verb whereas the other two don’t, but it still makes little sense to me that we have two properties with the same name, same description, and belonging to the same class of object that return different values.

Since that radar isn’t about System Events in particular but the underlying API, I’m going to BR it against System Events in 10.13 (at least that way I know it’ll get seen).

#4

No – but it returns exactly the same results here, so it’s not unreasonable to assume System Events is using something similar. (Assuming you see something similar there.)

Quite right. Assuming it is the explanation, it means the engineer on System Events made the same wrong assumption about what NSURLVolumeIsEjectableKey means as the person who posted the radar.

(I wouldn’t be surprised if the Finder is using some older Carbon API – using NSURLVolumeIsRemovableKey as mentioned in the bug report still doesn’t match the Finder’s result.)

#5

But using it along with NSURLVolumeIsLocalKey seems to:

	set theList to {}
	set allVols to (current application's NSFileManager's defaultManager()'s mountedVolumeURLsIncludingResourceValuesForKeys:({current application's NSURLVolumeNameKey, current application's NSURLVolumeIsInternalKey, current application's NSURLVolumeIsLocalKey}) options:0)
	repeat with aVol in allVols
		set {theResult, isLocal} to (aVol's getResourceValue:(reference) forKey:(current application's NSURLVolumeIsLocalKey) |error|:(missing value))
		if isLocal as boolean then
			set {theResult, isInternal} to (aVol's getResourceValue:(reference) forKey:(current application's NSURLVolumeIsInternalKey) |error|:(missing value))
			if (isInternal is missing value or isInternal as boolean is false) then
				set {theResult, volName} to (aVol's getResourceValue:(reference) forKey:(current application's NSURLVolumeNameKey) |error|:(missing value))
				set end of theList to volName as text
			end if
		end if
	end repeat
	return theList

Does that return the same result as the Finder there? If so, you might suggest it as an approach in your bug report.

Lots more code, 1/10th the execution time…

#6

Returns the correct results here.

I’ll add it to the BR later. Thanks. :+1:t3: