Did Time Machine put 274 GB of data in my Volumes directory?

Question

Level 3

872 points

Did Time Machine put 274 GB of data in my Volumes directory?

My first hint that something was wrong was that Carbon Copy Cloner complained that my 600GB encrypted disk image wasn't big enough to hold my backup.

I knew that couldn't be write. My data was roughly 300GB.

So I fired up the superb (free) OmniDiskSweeper and found there were 274GB of data in my /Volumes directory (hidden system folder, to visit it with Finder use "Go To Folder" and type Volumes.

That Folder normally holds Unix Aliases, not files.

It turned out to hold two copies of my hard drive, one fairly complete, the other a mere 40GB, both dated within one day of Jan 26, 2011. They were named after my Time Capsule hosted Time Machine image.

I'm pretty sure TIme Machine put them there during a Time Capsule backup. I've never seen reports of this, but I have seen reports of similar behaviors with disrupted Time Machine backups to a local firewire drive.

I deleted the 600,000+ files and OmniDiskSweeper reported Volumes now uses 12kb.

Has anyone else heard reports of this? I'd guess I'm not the only person who's experienced this, though some friends claim I'm cursed. I don't think it impacted my backups much, neither Time Machine nor SuperDuper nor CarbonCopyCloner actually copy the /Volumes folder, there's not supposed to be anything important there.

i5 iMac 27, iPhone OS 3.1.2, MacBook Core-2 Duo, G5 iMac, G3 iBook, Mac mini

Posted on Jun 22, 2011 7:43 PM

Reply

Answer 1

Best reply

Francine Schwieder

Level 6

19,052 points

Jun 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.

Francine

Reply

Answer 2

Pondini

Level 8

38,863 points

Jun 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.

Reply

Answer 3

jfaughnan Author

Level 3

872 points

Jun 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 ...

Reply

Answer 4

Jun 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.

Francine

Reply

Answer 5

Jun 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.

http://www.pinkmutant.com/articles/TigerMisc.html

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.

Francine

Reply

Answer 6

Pondini

Level 8

38,863 points

Jun 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.

Reply

Answer 7

jfaughnan Author

Level 3

872 points

Jun 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:

http://tech.kateva.org/2011/06/omnidisksweeper-finds-247gb-in-my-os-x.html

Reply

Answer 8

Jan 2, 2012 10:09 PM in response to jfaughnan

Maybe a good tip to prevent dopplegangers hidden in Bombich CCC website?

http://help.bombich.com/kb/dmg-and-remote/a-caveat-for-backing-up-to-a-remote-ma cintosh-that-has-no-user-logged-in

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.

Reply

Answer 9

steve626

Level 6

10,439 points

Jan 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.

Reply

Answer 10

Pondini

Level 8

38,863 points

Jan 3, 2012 8:27 AM in response to steve626

steve626 wrote:

. . .

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.

Reply