On Mar 17, 2014, at 9:40 AM, koenig.yvan < email@hidden> wrote: SE return three infos in a single string : Macintosh HD - which is redundant but is not wrong -100 - which is identical to the Finder's id 2 - which means something but who knows what. If there is a true problem here, it's certainly not the difference between id from Finder's point of view and id from System Events' one, it's just what is the meaning of the third component.
The first component is, obviously enough, the name of the item. The second component is the ioVRefNum (volume reference number) of the disk volume containing the item. The third component is the inode number of the item.
Note that inode numbers are volume-relative. The inode number is not unique unless the volume is also specified.
The inode number of the root of an HFS filesystem is always 2.
The ioVRefNum is assigned dynamically when the volume is mounted. If a volume is unmounted and remounted, it may get a different ioVRefNum. The boot volume gets assigned first, so it gets -100. It's never unmounted, so it keeps that number.
Finder returns only the ioVRefNum, because that's sufficient to identify a (currently mounted) volume. It doesn't need to return more, because Finder will not return an id for a file or folder.
System Events returns more info, so it can return unambiguous ids for files and folders, not just disk volumes.
/bin/ls with the -l and -i flags will reveal the inode number. You can verify for yourself that this agrees with the number returned by SE.
-Ron Hunsinger |