Jump to content

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


Recommended Posts



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:




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.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...