bad superduper backup - null files

[FSU_Math]

So, to make a long story short, I made a backup of some direrctories, but in the image, most of the files in one directory tree can't be opened. These files are the proper length and have the proper attribute, but are apparently full of null characters. "sum" returns 0 for the total of the bytes, and cat'ing the file gives no output.

What could have happened in the backup procedure? How can this be prevented in the future? Superduper returned no errors when it ran (the window turned green).

[dnanian]

It sounds like the image itself got corrupted, and the OS didn't indicate there were any problems writing the files when we did it. Was it stored on a properly formatted HFS+ drive? Did anything happen to that drive or the Mac that might have corrupted the image itself?

[FSU_Math]

the drive is the one I've used for a long time, never had a problem in the past (not that past performance is any indication of the future). The only mildly negative thing I can think of was that the drive was nearly full after the image was created (the one that turned out bad). Could that have caused it, ie filling the drive but not receiving or misinterpreting the error?

It's my understanding that superduper dynamically requests the space allocation, so could the files in question be at the "end" of the backup and so have fallen off the end? A bit more information, the back up script was a "backup - user files" and the files in question are in the Desktop directory of the last user alphabetically. Does Superduper run through the file list alphabetically or by some other method? I'm trying to find a reason as to why these specific files (and not others on the image) are corrupted.

[dnanian]

It's possible that, if the drive filled "outside" the image, and the image didn't report an error -- or one of the internal OSX copying APIs indicated success on a retry, even though it failed -- then the written files would be damaged. But we wouldn't continue unless OSX itself told us the copy was successful.

No question, though, having insufficient space for your image to grow is unwise: as I mention in the User's Guide, all sorts of catastrophic things can happen if an image is prevented from growing (including kernel panics).