Retrospect client looks to hidden /Volumes directory to populate available source volumes, which causes serious problems

[cbj4074]

http://forums.retros...post__p__252066

 

To summarize the issue, the Retrospect client scans Mac OS X's hidden /Volumes directory in order to populate the list of available source volumes on the client. This is a major problem due to the issue described at the following URL:

 

http://support.apple.com/kb/TS2474

 

Even though the above KB article lists 10.5 as the most recent OS that is affected, that is incorrect; this issue affects 10.6 and probably 10.7, too. It is a fundamental design flaw in the OS. Maybe it's a flaw with BSD, in general.

 

One commenter summarized the issue thusly ( http://ask.metafilte...Volumes#2289303 ):

 

Essentially the OS creates an alias in the Volumes folder for every volume mounted. When you dismount the volume this gets removed.

 

If you just pop it out this alias gets left behind.

 

In 10.4 and 10.3 this could create problems with some flash media, as if the alias of the same name was already in the Volumes directory it wouldn't allow the card to mount until you deleted the ghost volume.

 

The contents of the /Volumes directory cannot be relied upon, especially where mission-critical software (e.g., Retrospect) is concerned. To understand just how unreliable it is to use /Volumes, consider two USB thumb-drives with the same volume name (very common if the memory sticks are of the the same make/model). The order in which the drives are inserted will affect the alias/mount-point to which the each volume is assigned within /Volumes. If both volumes are named "SanDisk", for example, the first volume will be mounted at "/Volumes/SanDisk" and the second at "/Volumes/SanDisk 1". Now, if Retrospect is told to remember "SanDisk 1", and both drives are ejected and inserted in the opposite order, Retrospect will look to "/Volumes/SanDisk 1" and will have the wrong disk.

 

The Retrospect client should use an alternative means of acquiring the list of available volumes. More specifically, the client should ignore /Volumes completely (it cannot be trusted), and instead use command-line utilities to poll and catalog volume information.

 

Retrospect should use a combination of calls to mount, diskutil list, and diskutil info to determine which volumes are present and whether or not a given volume is among them. In particular, when polling media, Retrospect should require the "Volume UUID" for a "known" volume to match Retrospect's internal media database before considering the volume to be a match. This would prevent restoring media to the wrong disk, accidentally (and through no fault of the user), among various other conflicts and problems, such as that described in my original post.

[Don Lee]

I want to add that the UUID on some removable volumes has not been entirely stable for me.

 

I cannot reproduce it now, but I had call to try to use the UUID to match up removable volumes, and I found that the UUIDs would sometimes change if the disk were unmounted and re-mounted.

 

YMMV