Time Machine hard link to ORIGINAL file
Hi. This is my first forum post. Usually googling for threads is sufficient, but I can find nothing on this. I think I've stumbled into a very dark corner of Time Machine.
I created a large file in my user space (4Gb -- a tarball, but I don't think that's important). I went to gzip it, and gzip kindly informed me that the file had two hardlinks to it, so it would not cooperate (rightly so). I worked around that problem, but I nearly flipped for an hour thinking that my file system had some serious error (wrong hard-link count, therefore, who knows what else).
Using
% ls -i <filename>
% sudo find / -inum <inode-from-previous-command>
I figured out that the second link to the inode was in the ./MobileBackups directory (ie, where Time Machine does its Time-Machine thing). It would appear that in order to save space on the local drive, it is using hard links to the ORIGINAL data. I understand that Time Machine uses hard links in its internal incremental-backup structure, but linking to the original seems like a bad idea (only the most minor consequence of which was this little gzip flip-out). Anybody able to tell me if I encountered a bug (such that I should be concerned for my data), or is this just an "undocumented feature?"
I also don't really want this tarball living in my backups, which is what will probably happen when I rm the original link (I was just shipping it off to another machine), but I'm not super opposed to it either, since that is what Time Machine is supposed to do. Any advice there?
I created a large file in my user space (4Gb -- a tarball, but I don't think that's important). I went to gzip it, and gzip kindly informed me that the file had two hardlinks to it, so it would not cooperate (rightly so). I worked around that problem, but I nearly flipped for an hour thinking that my file system had some serious error (wrong hard-link count, therefore, who knows what else).
Using
% ls -i <filename>
% sudo find / -inum <inode-from-previous-command>
I figured out that the second link to the inode was in the ./MobileBackups directory (ie, where Time Machine does its Time-Machine thing). It would appear that in order to save space on the local drive, it is using hard links to the ORIGINAL data. I understand that Time Machine uses hard links in its internal incremental-backup structure, but linking to the original seems like a bad idea (only the most minor consequence of which was this little gzip flip-out). Anybody able to tell me if I encountered a bug (such that I should be concerned for my data), or is this just an "undocumented feature?"
I also don't really want this tarball living in my backups, which is what will probably happen when I rm the original link (I was just shipping it off to another machine), but I'm not super opposed to it either, since that is what Time Machine is supposed to do. Any advice there?
Comments
Anybody able to tell me if I encountered a bug (such that I should be concerned for my data), or is this just an "undocumented feature?"
It seems to be partly an issue with Gzip:
http://jeremy.zawodny.com/blog/archives/010745.html
but Time Machine is obviously adding to it by using hard links. Applications like Carbon Copy Cloner generate comparisons between the source and backup every time you run them (which takes a bit of time) so maybe Time Machine just keeps a set of permanent hard links so it can check the inode references quickly to determine which files have changed.
It shouldn't affect most people but some command-line apps that have been around for a while will have a spaz out now and again.
I also don't really want this tarball living in my backups, which is what will probably happen when I rm the original link (I was just shipping it off to another machine), but I'm not super opposed to it either, since that is what Time Machine is supposed to do. Any advice there?
You can add exclude folders to Time Machine and put the tarball in there. That'll probably prevent Time Machine creating hard links to the contents.