Home Forums Mac Software Mac Operating Systems Time Machine Drive Problem

I was trying to make room on my TM drive, and forgot that Ganbustein had said I could delete the SYSTEM folder inside the backups and instead moved two of the dated backup folders to the trash. Trash won't empty and it won't let me put them back. They are from the backup folder of the first of three drive backup folders.

Try turning Time Machine "Off" in System Preferences, then try what you want to do. You may need to unmount the Time Machine drive and then remount it as well.

Just a thought.

Nope. Same problem.

A shot in the dark, probably, but have you tried restarting?

(I assume you tried "Secure Empty Trash".)

I restarted and it is still not allowing me to put them back. Even when I change the permissions on the TM drive, I can't do it. After the messages I got, I'm not sure I should keep trying to delete those folders in the trash. I could use Onyx, I suppose, to force delete them, but I'm not sure what effect that would have on the other sets of backups.

I never said anything could be trashed out of your Time Machine backups. Starting with Snow Leopard, Time Machine protects its backups using a feature called Mandatory Access Controls. Even the root user cannot override MAC. I'm surprised you were even able to drag those backup folders to the trash. Finder should have balked before completing the move.

You can delete things from your backup, but not using Finder or Terminal. You have to ask Time Machine to delete it for you. (And TM will delete it, not merely trash it.)

The easy way begins with making sure your Finder windows are showing the Action menu in their toolbar. (The Action menu is there by default, but you may have deleted it using either command-drag or via View→Customize Toolbar... . You can put it back using View→Customize Toolbar... . If you're showing icons in the toolbar, it's the menu with a gear icon.)

The Action menu is context sensitive. That is, what's in the menu depends on where you are. When you're in Time Machine's starfield view, the Action menu will contain a Delete All Backups of "whatever is currently selected" menu item. Once you've gone back in time, it will also contain a Delete Backup menu item.

The former command, as its name suggests, deletes the selected item from every snapshot it's contained in. Great for destroying incriminating evidence from your backups. (But unless you also delete the current copy, or exclude it from future backups, the very next TM snapshot will put it right back on the backup.)

The latter command deletes the snapshot you're viewing. It's as if Time Machine didn't run at that time. Great if you want TM to forget noticing that a particular drive wasn't mounted last time around.

Normally, everything in the Action menu is also available in the menubar, but Time Machine's starfield view does not have a menubar. The Action menu is the only way to access these commands, and you can't even add the Action menu from within TM. You have to add it in Finder, in anticipation of needing it in TM.



The other way to delete things from a TM backup is through the tmutil shell command, first introduced in OS X 10.7 Lion. (man tmutil for details.)

Whether you're using the tmutil command or the Action menu, notice that it's Time Machine itself that is doing the deleting. Mandatory Access Controls allow TM, and only TM, to modify a Time Machine backup.



I do not recommend excluding or deleting system files from your TM backups. Doing so would make a full disk restore unbootable. Besides, your System folder is only about 7GB. If saving 7GB makes a meaningful difference, your backup volume is way too small.

I wasn't in the TM starfield, I did it in the finder using the action dropdown and used 'move to trash', not 'delete'. What's done is done. Is there a way out that I can understand and do?

I just tried 'put back' from the trash menu, but I get same error.

Yes, I got that.

But I don't understand how you were able to do even what you say you did. I have no idea how to put it back.

What OS are you running? OS X 10.5 Leopard did not have Mandatory Access Controls. You could do things like this on Leopard.

Well, maybe I have some ideas. If you really moved it to the Trash (as opposed to copying it), it's still inside the .Trashes folder on the Time Machine volume. You should be able to delete that trash folder with

sudo rm -rf /Volumes/"name of your backup disk"/.Trashes

Be very careful typing that command. Any command that begins "sudo rm -rf" is scary. Be very sure you do not introduce extraneous spaces in the rest of the command.

It's OK to delete .Trashes. The system will re-create it when needed.

If you get errors from that, some of the files may be locked. Even root must respect the locked flag, but only a little. You can unlock any locked files with

sudo chflags -R nouchg /Volumes/"name of your backup disk"/.Trashes

after which you can delete them using the first command. There may also be ACLs on the files, but root ignores ACLs. You can remove them anyway, if you want, with:

sudo chown -RN /Volumes/"name of your backup disk"/.Trashes

The "quotes" are part of the command line?

My TM disk has a space in it's name-- Time Machine

The quotation marks are part of the command. Leave them in. Substitute the name of your backup disk—in your case, Time Machine—for name of your backup disk.

The quotes are there specifically to handle instances like yours in which the volume name includes a space. ganbustein's "extraneous spaces" refers to the rest of the command. If you left a space before .Trashes, for instance, you'd be telling Terminal to delete your entire backup volume.

Thanks. Worked!

Silly me. The -f flag (in rm -rf) says, among other things, to blow right past any impediments like locked files that have obvious circumventions. Any locked files encountered will be silently unlocked to allow removal.

Or you sure that it worked? Have all the very complex file linkages in a Time Machine backup been successfully restored or have you just moved the files and folders out of the Trash folder without re-establishing or verifying the linkages? I don't know how to check that out, but perhaps someone like Gangbustein or DK do.

I confess to being pretty anal about Time Machine backups, but there is a reason Apple does not want anything but Time Machine moving files in the backup set and that is the very complex multi-linked structures used in Time Machine. If it were me, I would probably charge the entire experience off as a learning exercise, write off the historical backups, erase the Time Machine drive, and create a new Time Machine backup set from scratch just to be sure my backup will work, if and when it is needed.

One of the beauties of Time Machine is that its data structures are dead simple. Apple had to make some serious changes to the OS and to HFS+ to make Time Machine fast or even possible, but the end result is not at all complex.

That's what you want in a backup system, and is in stark contrast to some other backup software (<cough>Retrospect</cough>) that maintain extremely complex and highly proprietary databases of everything in the backup.

The "highly complex" links you're talking about are simply hard links. Unix normally disallows hard links to directories, and HFS+ did not originally support hard links at all. Apple had to change HFS+ for OS X 10.0.0, to support the hard links that the Unix underpinnings of OS X required. And then they had to change it again in OS X 10.5 Leopard to support hard links to directories, to support Time Machine. Even now, only TM is allowed to make a hard link to a directory (beyond the fact that each thing in a directory is implicitly hard linked to it, but I'm talking about explicit hard links).

But the patches have been made, and the HFS+ filesystem knows all about hard links. In particular, it knows how to break them and how to count them. Deleting a file or folder means reducing its hard link count by 1. If that takes the count to zero, the "real" file or folder (the "inode" in Unix parlance) gets deleted, freeing up any space it was using. It doesn't matter when or in what order the hard links were made, or by whom, nor when or in what order they're broken. The inode survives as long as any hard link to it (including the one every file/folder is born with), which is exactly how long it needs to survive.

It all just works. HFS+ doesn't need to know anything about Time Machine, because Time Machine prudently left its backup in a state where HFS+ doesn't need to know. This stark simplicity makes TM future-proof, too. Lion and Mavericks can read and understand each other's TM backups with ease. There's no reason to suspect the format of a TM backup need ever change. They designed it right the first time, precisely because they designed it simple.


Just to work out an example: the OP says he deleted the two oldest TM snapshots from his backup. Let's suppose those were the first two TM made. Consider a file that TM backed up during the initial backup, and hasn't touched since. TM will not have backed up that file ever again, because it sees it has already been backed up.

But now, the OP has deleted that original snapshot. Is the file gone?

No. Each time TM saw that the file did not need to be backed up again, it added a hard link to it. The file has as many hard links as there are snapshots that saw it. The OP deleted the two oldest snapshots. That reduces the hard link count by 2, but as long as there are still later snapshots linked to it, HFS+ still sees a positive link count to it, and does not delete the actual file.

Suppose at the other extreme that a file got backed up in the original snapshot and then deleted from disk. The underlying file is still backed up, but with a link count of 1. The OP moved that snapshot to .Trashes, but that doesn't change the link count. (The link count of Backups.backupdb was decreased by 2, because it now contains two fewer folders and every folder has a hard link to its parent. The link count of some subfolder of .Trashes increased by 2, because it now contains two more children. No other link counts changed.)

Now the OP tells rm to remove .Trashes. The -r flag to rm tells it to delete files recursively, so it walks the tree, reducing by 1 the link count of everything it sees. It comes to this file, reduces its link count to zero, triggering the release of all of its disk space back to the available pool. The "real" file got deleted exactly when it was supposed to.

The rm command didn't know this was going to happen, and doesn't care. It just issues the unlink(2) system call, which figures out which disk volume the file being unlinked is on, discovers that that volume is being managed by HFS+, and asks HFS+ to delete the file. HFS+ does the right thing.

It all just works. That's the beauty of Time Machine. There is, at heart, nothing complicated going on. Simple is beautiful.