Time machine - some files are zero kb

[skullmunky]

I've just discovered that some of the files in my Time Machine backup are empty (zero bytes). They're not all in one place - a few in one directory, a few in another, all totally normal user files, not system files or anything that would be excluded from the backup. They're not all from one snapshot - the empty files appear in different snapshots going back over the last two years. All the original files are, happily, all still alive and well on my laptop, so nothing is actually lost - but this makes me uneasy. The empty files are all different types - Photoshop files, JPG's from my camera, Word files, Gimp files, PDF's, Python code, MP3's, etc.

My time machine backup is on an external USB drive. It has plenty of space ( >200GB free). I ran Disk Utility and the backup drive verified clean. Doesn't rule out some kind of nasty bad block problem. But, it seems like Time Machine is occasionally creating files but not copying any data into them. I checked the logs in the backup directories and didn't see any errors. Are there any cases where Time Machine might silently fail like this? Weird file metadata, ACL's, extended permissions, anything?

 

[Kaveman]

Oh dear, don't go rummaging through a TimeMachine backup, it uses some extremely clever ways of building file trees over time with Hardlinks and other tech. You access TimeMachine backups via the TimeMachine Software.

 

[skullmunky]

Yes, I know. The problem I'm having is that there are files that Time Machine has backed up, and the backup versions are empty. If I enter Time Machine and check the current version of a file, which TM calls "Now", the version which is on my MacBook's internal HD, it's, let's say, 68K on disk. If I scroll back to previous backups in TM, each of them says the file is Zero KB. This is true for all versions of the file in TM. They're files that I have not changed since they were created; so as expected there's no difference between any of the versions in TM, but each version is 0 bytes when it should have, well, some bytes in it.

I was looking at the logs from the terminal because there isn't AFAIK a way to view them in TM. This seems like there were copy errors during the backup, so I wanted to check the logs to see if there were errors. There weren't any errors in the logs.

Here's what's even stranger. I used Super Duper to clone the MacBook's drive to a sparse disk image. I mounted the disk image and checked the files that were having this problem. They're Zero KB in the disk image too! It's the exact same scattered handful of files ... all other files I've checked are ok. In technical unix terms, this is, like, SOOOOOOOOOOO WEIRD!!

 

[skullmunky]

Solved it .. at least I think, anyway. My end goal was to get all my files onto a new laptop; I just discovered this issue with my Time Machine backups from the old laptop while doing that process. This was a fun adventure, so I'll share the steps I took in case helpful to others.

I put the old laptop into target disk mode and tried copying the files over that way, just dragging and dropping them one by one. Same problem - no errors, but the resulting file on the new laptop is zero kb.

But doing the copy from the terminal worked perfectly.

One thing I discovered was that a lot of the files had odd flags set - not just uchg, the "locked" attribute flag, but various combinations of nodump, compressed, uappnd, and opaque. at the very least this was sometimes preventing me from repeating the copy operations, because the bogus empty files on the destination drive still have these flags that the originals had. so I used the chflags command to clean up flags in any directories where these files are, both on the source and destination drives:

chflags nouappnd,nouchg,dump,noopaque,nocompressed *

that did still leave me with about 450 files that I need to rescue.

First, to find out what files, I used find:

find . -size 0

stored that in a text file and pruned files that actually are supposed to be empty. then wrote a python script to copy each file from the source drive to the destination drive by replacing the path prefix. random spot-checked the resulting files, all seem good.