Currently Being ModeratedJun 23, 2011 9:29 AM (in response to jfaughnan)
Any backup program whose connection to its designated backup drive gets bolluxed up can, and sometimes do, make an actual folder in /Volumes and backup to that folder. I don't recall Time Machine in particular doing this, but I have seen reports of this behavior for years using a wide variety of backup programs. It is such a common mishap that it is one of the first things to check when your drive mysteriously announces that it is full (that and run-away log files probably account for 80 or 90 percent of the cases of missing drive space).
If it happens again you may want to investigate to try to determine WHY you are losing the connection to the backup drive.
Currently Being ModeratedJun 23, 2011 4:28 PM (in response to Francine Schwieder)
Francine Schwieder wrote:
. . .
I don't recall Time Machine in particular doing this
Yes, it does happen on occasion, though as you say it seems more frequent with cloning software for some reason. The clue is, if there's a Backups.backupdb folder (for backups to an external HD), or a sparse bundle (network backups), it was made by Time Machine.
Currently Being ModeratedJun 23, 2011 4:36 PM (in response to Francine Schwieder)
Thanks for confirming my suspicions.
One curious thing -- I had a hard time finding anything about this on Google, despite it being known to the both of you. I did find a few comments in the discussion groups here, but not all that many.
Something for Google to look at ...
Currently Being ModeratedJun 23, 2011 4:38 PM (in response to Pondini)
Interesting! I hadn't noticed anyone complaining about Time Machine doing this before, but have seen complaints about pretty much all other backup programs, at one time or another.
I've never written any program beyond "Hello World" so I suppose I shouldn't say this, but I will anyway: it seems to me that it shouldn't be that hard to have a routine in any and all backup programs that would forbid this very bad behavior. I've never understood why the programming allowed the backup application to create a directory at a mount point and write to it. It would make more sense to have the program throw up an error message when it is doing its thing and it loses connection to the designated backup drive.
Currently Being ModeratedJun 23, 2011 4:42 PM (in response to jfaughnan)
You may have picked the wrong search terms: if you do a search on "disappearing drive space" lots of things come up, including an article I wrote way back in Tiger days that discusses most all the culprits, including backup software.
Most of the info in the article is still apropos, although I believe a couple of other things that gobble space have come up since then.
Currently Being ModeratedJun 23, 2011 4:47 PM (in response to Francine Schwieder)
Try looking for doppelganger folder (yes, spelled that way). Here's one: http://db.tidbits.com/article/9620
Since that's not exactly a common term, I call them "False volumes" in the blue box here: Where did myDisk Space go?
Apparently the glitch is, the connection gets established and the alias connected or created, then while the app is getting ready to use it, something goes wrong. But the app may not get notified properly, or doesn't handle the notification. So it tells OSX to write something to /Volumes/<folder name> and, since there's no alias there, OSX obligingly creates a folder.
Currently Being ModeratedJun 25, 2011 5:54 PM (in response to jfaughnan)
I received several excellent responses to this post. Since I had trouble finding references when I searched Google, I've updated a tech blog posts of mine with links to the recommended references. I'll submit that URL to Google and perhaps it will speed future troubleshooting.
This certainly smells like an OS bug, and since its longstanding I assume it is very hard to fix. Probably a deep issue. Still, I can imagine several things Apple could do to help.
I suggested on the Onyx site that Onyx add a check for data in the /Volumes folder in its cleanup options.
Here's the blog post I wrote:
Currently Being ModeratedJan 2, 2012 10:09 PM (in response to jfaughnan)
Maybe a good tip to prevent dopplegangers hidden in Bombich CCC website?
I am going to do this and see if it prevents this problem from happening
A copy of the link's text follows because he sometimes deprecates a real gem posted in his support site.
A caveat for backing up to a remote Macintosh that has no user logged in
For "improved detachability", Mac OS X will unmount any non-internal volumes that are attached to the system when you log out. So, for example, if you log out of your computer while a USB or Firewire hard drive enclosure is attached, you can detach those hard drive enclosures from the system without having to manually unmount them first. This is a good thing — it would be annoying if you had to log back in to your system just to eject a drive. The downside of this, though, is that if you have a scheduled backup task that runs when no user is logged in, the destination volume may be unavailable. For a local backup, CCC will attempt to manually mount the destination volume. When the destination of your backup task is a remote Macintosh, though, CCC will not be able to mount that volume prior to backing up.
If you anticipate backing up to a remote Macintosh that may be sitting at the loginwindow, you can change the behavior of Mac OS X to not unmount detachable volumes. To change this behavior, run this command in the Terminal application on the remote machine:
sudo defaults write /Library/Preferences/SystemConfiguration/autodiskmount AutomountDisksWithoutUserLogin -bool YES
Note for Snow Leopard users: This workaround does not work on Snow Leopard 10.6.0 to 10.6.3. If you require this functionality, please apply the 10.6.4 update (or the latest available) for the best experience.
Currently Being ModeratedJan 2, 2012 10:20 PM (in response to jakemooremd)
In addition, if you check the forums for CCC and for SuperDuper, you will find instances where the target volume for a backup was unavailable (similar to what what described above by jakemooremd) and the backup gets written instead to the /Volumes directory, eventually causing the source hard drive to fill up. It can happen not only if the target volume is ejected, but also if it is powered down or physically disconected (USB or firewire cable pulled out). Unable to find the target volume, the backup program (CCC or SuperDuper) will create it within that /Volumes directory and write the backup there. Not desirable behavior, but that's what happens.
From the very first post, I am suspecting that CCC is what did this.
Time Machine is designed so that if the target volume is not available (dismounted or disconnected or not powered on), Time Machine waits until the next time it is available. Millions of people using laptops that are transported frequently far away from the Time Machine backup disk depend on this behavior, and it does do this consistently, so I doubt Time Machine is the culprit.
Currently Being ModeratedJan 3, 2012 8:27 AM (in response to steve626)
. . .
Millions of people using laptops that are transported frequently far away from the Time Machine backup disk depend on this behavior, and it does do this consistently, so I doubt Time Machine is the culprit.
Time Machine will do it, rarely, with a full restore, apparently if the connection is lost at just the wrong time.
It will also do it in either of these unusual circumstances:
- Trying to do a full restore the wrong way, by selecting your internal HD in the "Star Wars" display and clicking Restore. (That seems fairly reasonable, and Apple doesn't warn you not to try it that way.)
- If you're trying to restore some or all of the backups of a no-longer-connected drive, you get this prompt:
If you select Recreate Enclosing Folders, it will put it in /Volumes.