Solution to Lion SuperDuper problem

I just heard back from Dave Nanian at Shirt Pocket. (On a Sunday during the Super Bowl! I love that company.)

Here is his message:
_____
Time Machine stores its local snapshot in the .MobileBackups folder on the source drive when you're using a laptop.

Rarely, this folder is in a state that makes it uncopyable. If you get an error like this, there are four things you can do:

• Wait for the next actual Time Machine backup to occur, which will flush the folder
• Temporarily turn Time Machine off, which clears the snapshot
• Use "sudo tmutil disablelocal" to turn off local snapshots
• Create and use a copy script that ignores /.MobileBackups (which is more complex for the user, but will be the default in the next version of SuperDuper.
_____

So that's the answer. You can ignore the second two suggestions. When the next version of SD comes out, it will be fixed for good.

BTW, none of this affects SuperDuper users in Snow Leopard or Leopard. It's a Lion-only problem.

Apropos of Lion, I determined that there is no way to downgrade Safari to version 5.0.5. Lion 10.7.0 shipped with, and requires, 5.1 or later. Now we just gotta wait for Apple to fix the mess.

10.7.3 Update Results

Lion Update

Well, I did the update to Lion 10.7.3, and I see no change in performance or features. The update included a jump to Safari 5.1.3, which did NOT fix the problem it has been having with pages not responding, and requiring a forced reload of all open pages.

Obviously Apple knew about the problem or they wouldn't have included the dialog box, which did not exist (or at least, was never invoked) in 5.0.5 and before.

Biggest fail, however, is with SuperDuper. It cannot copy a specific invisible folder called /.MobileBackups, which exists at the top level of the hard drive. It fails with a Type 8 due to error 28: No space left on device. This is actually not true; the target drive has three times as much free space as the source drive it is copying.

I sent the report to Shirt Pocket Software, publisher of SD, and maybe they will have a response next week. You who use SD, be sure to click the Send to Shirt Pocket button at the bottom of the report, which you see by choosing the Show Log item in the Window menu, any time your backup fails.

That .MobileBackups folder exists to save older versions of files like TimeMachine does, but it works when the T-M backup drive is not present. I can't blame this on 10.7.3 because it appeared when backing up the 10.7.2 Lion disk before I ran the updater.

I went through half an afternoon trying to clear out that folder, too. First, it's invisible so I have to run the widget "Hidden Files" in order to have the Finder show all invisible files and folder. Then, when I could see it, that folder had a NoEntry icon on it, which told me I could not open the folder because I didn't have enough privileges.

Root User did not help

Okay, I have to get those privileges, so I enable Root User on my Mac and log in as that. This lets me open things not available to a simple Administrator, but lo, the Hidden Files widget cannot be installed and run in Root. So off to Google I go to find the Terminal commands that will enable hidden files. That works. However, when I open the now-readable .MobileBackups folder, I see the items that are causing the problems (as well as wasting 4 gigs of drive space) but it won't let me delete them! Even as root! I am truly playing in a sandbox that Apple does not want anyone to play in.

The failure was caused by some Safari files. After banging around a bit I was finally able to make them go away and lo, the SuperDuper backup works. I return to normal user mode and run the backup so I can load the 10.7.3 update.

When all this was finished, I plugged in a larger hard drive, one big enough that I could partition it to support both Time Machine and SuperDuper backups. Set to run that night, I wake up to a SD failure again, with the same error message pointing to the same /MobileBackups folder, but with a different file in it: the 10.7.3 Combo Update!

This is where I gave up and am waiting to hear from Shirt Pocket.

Addendum

I got a short answer from Shirt Pocket just now: It seems the only workaround is to turn TimeMachine OFF (in System Preferences, Time Machine) for 10 minutes before running SuperDuper. I wrote back and answered if this is something that can be fixed in the next SD update. Will post when I hear back.

Beware The Recent Items Menu

Been a while since I had anything to report, but this one is a doozy. I was called out to recover a lost Excel file, in which the client had entered data for three days, and then found the next morning that anything entered between 12/29 and 1/3 had vanished.

They thought they had mistakenly saved the file somewhere else, or under another name but could not find anything. To make the search even easier, there were only three Excel files on their drive. But everything was dated the 29th as the last changes made!

I entered TimeMachine and yep, every file ended at the 29th. I checked their SuperDuper backup as well, and the same thing was true. Each time, the typist had opened the file and the changes had been there, the 30th, the 31st, but on January 2nd when they came back to work, all the typing was gone.

This one beat me too. There was nothing to search for: no cache files (preserved usually only to recover from a crash) and no other temp files anywhere. Ready to throw up my hands, I went into Excel and looked under the Recent Items menu and there were two documents there, one on the cloned backup and one on the internal drive. But the path name in the menu was incomplete. The first part of the path was cut off.

Usually a path name shows where the file is, i.e.

Macintosh HD/Users/Home/Documents/Specific Folder/Name of the file.xls.

In this case, there were two looking like this:

.../Home/Documents/Specific Folder/Name of the file.xls

.../Home/Documents/Specific Folder/Name of the file.xls

There was no clue as to which was on the Macintosh HD and which was on Clone Backup. A bright, bold AHA lit up the room.

What the person had done was not go into the correct folder in Documents to open the file, but instead opened from the Recent Items menu under File in Excel. Most of us do this. But one time he accidentally chose the item on the Clone Backup drive, because the drive name did not show. That made it the more recent of the two, and put it above the one on Macintosh HD. Each further edit was done to the first item.

They did not catch the mistake on the second day because their SuperDuper backup was set to run only once a week, not daily as usual. So when it did run over the holiday, it dutifly cloned the internal drive to the external, overwriting the newer file on the backup drive with the one last opened Dec. 29th.

Of course TimeMachine was no help because it doesn't index clone-backup drives, just the internal. Hence, nothing newer than 12/29. In the 20 years I have been fixing Mac problems, this is the first time I have run into this. There was indeed no way to get the missing work back, but it gave ME fodder for this blog, and a warning to everyone: Be very careful when using the Recent Items menu. It's a lot safer to simply open the folder where your document is living and open it from there. No chance for a mistake like this to happen.

SuperDuper Super Oops

This is a case of SuperDuper out of control. I was investigating problems with a MacPro that had too much stuff on the hard drive. I launched Grand Perspective, a great app that gives a colored graphical representation of what files are on the drive and how big they are.

I noticed a large section filled with files that started with the path name of the backup drive. Now, normally Grand Perspective only shows the drive you ask it to inspect. I should not have been seeing what I was seeing. Tracing the path, it seemed that it started in the Volumes folder, an invisible folder on all OSX drives.

I made it visible using the widget "Hidden Files" and opened it up. This folder normally contains only aliases to drives plugged into the Mac, including the internal drive(s).

There was no alias for the backup drive. Instead there was a folder with the name of that drive and a second folder named the same but with a 1 at the end.

Switching over to SuperDuper and looking at the Schedule window I found five separate schedules, 15 minutes apart, two of which were in red. The backup was failing every time and I could not select the proper backup drive in its main window.

Somehow two of the schedules had pointed themselves into this Volumes folder and was dutifully backing up the internal drive onto itself in this invisible folder. The real folder had replaced the alias that should have been in Volumes and almost 400 gigs of files had filled it up.

Okay, delete. The first thing I discovered is you can't just delete from the Volumes folder. I would get a -8002 error if I even tried moving it to the Trash. Not knowing the technique to delete things in Terminal, I decided to enable Root and logged in as that. But the folder was invisible again. I tried installing the Hidden Files widget but it would fail to install! This was getting rather frustrating.

Okay, maybe it will work if I restart from my repair drive and log THAT into root and maybe it would let me install the widget there. I normally have Show Hidden Files always enabled when running from that drive so I thought, what the hell, I will try to delete those folders from here.

Surprise. It let me Trash those folders and then option-Empty Trash worked! I deleted both folders, one at a time, after ensuring that there was a successful TimeMachine backup in case my doing this destroyed the rest of the data on his drive. Not only did he have one, but Time Machine does not make copies of those invisible folders so I could have restored without also restoring the problem.

It takes a while to delete 385,000 files, even on a Pro. But when done, I ran Disk Warrior on the Pro's drive, which said it was okay. I restarted and not only did it boot just fine, with the almost 400 gigs of free space restored, but the Volumes folder now had a proper alias of the backup drive right where it belonged.

I created a new SuperDuper schedule and ran the backup and it went perfectly, with no failures.

The lesson for the reader here is that SuperDuper has a glitch that can get you in trouble.

Normally, when you set up the program, you click the Schedule button (after first defining the backup you want as a Smart Backup, not an Erase and Copy) and the window appears, followed immediately by a drop-down window that lets you pick the days and the time for the backup to run. This is how it should work, but the problem is after you create a schedule, the next time you click that button you get the same drop-down. What you must do there is click Cancel, then highlight the schedule script in the window and click Edit to make changes. If you just choose settings in the drop-down, it creates a second (third, fourth and so on) schedule, fifteen minutes later than the last (if you don't specify the time).

These extra schedules caused the problem, two of them having decided to install themselves in the Volumes folder. Then the schedules interfered with each other and the whole thing failed. So be careful when editing your schedule! It is okay to have multiple schedules, especially if you have a second drive with original material on it and you want SuperDuper to clone that drive to another backup drive (or second partition on your main backup drive).

There is a detailed PDF under SuperDuper's Help menu that tells you how to do all this and explains all the features, with pictures and descriptions. But how many users Read That Fine Manual?

Hint: I didn't read it either. I learned through trial and error.