does anyone else thing that's a bit backward, or am I reading it wrongly? wouldn't you want it to keep the unique files as long as possible, and delete the ones that were available on other backups?
First, let's agree on terminology.
Suppose you want to create a hierarchical filesystem on top of another filesystem. Call files in the underlying filesystem "
inodes" (internal nodes), and their names, as used by the underlying filesystem, "
inode names". The only way to access a real file is through its inode name, but you can create hierarchical pathnames of your own choosing.
Start by creating special files called "
directories", each of which contains nothing but a map from filename to inode name. Let there be one such directory file, the
root directory, whose inode name is well-known. To interpret a pathname like "/a/b/c", look up filename "a" in the root directory to get the inode name for "/a". With that inode name in hand, you can look in that directory file for "b" to get the inode name for "/a/b", and look therein for "c" to get the inode name corresponding to the pathname "/a/b/c".
In the original Unix Filesystem (UFS), the underlying filesystem was as simple as could be. An "inode name" was just a number, indexing into a table of inode descriptors, so in Unix we call it an "
inode number" instead of an inode name.
It's quite possible for the same inode number to appear more than once among all the directory files in a system. That's how hard links are created.
In UFS, the directory entry for a filename contains nothing but the corresponding inode number. Everything else about the file is attached to the inode itself: owner, group, permissions, create/modify/access date, flags, size, location on disk, etc. The only thing the inode does not have is a filename. It does, however, contain a link count, a count of the number of times that inode is referenced from any directory anywhere in the system.
All of that is conceptual, of course. Some filesystems, HFS for example, were designed to be hierarchical from the get-go. In HFS, files may but usually do not have inode numbers, directories always have inode numbers even though they have no corresponding inode, being merely records within the catalog and not standalone files. HFS+, among many other changes, requires all file to have inode numbers, and makes hard-linking possible through an elaborate and contrived process.
(Aside: the git version control system also implements hierarchical names the same way, except that an inode's name is a hash of its contents, which is always a valid name in whatever underlying filesystem you're using. This makes all inodes immutable, since the slightest change in content changes the inode name.)
But never mind the mechanics. It's conceptually easier to imagine that even HFS+ works like UFS. When we talk about a "real file" or a "physical file", we mean "inode". When we just say "file", it's ambiguous whether we mean "pathname" or "inode". Thus, if /a/b/c is hard-linked to /d/e, is that one file or two? It's two pathnames, but only one inode, so the answer is different depending on what we mean by "file".
That ambiguity is at the heart of your question.
The original
it deletes only the files that were unique to that backup (i.e., files that no longer exist anywhere in the file system).
should have been phrased
it deletes only the inodes which had no pathnames outside the backup (i.e., not anywhere else in the file system).
You're thinking it's OK to delete a file that you have other copies of. But if by "file" you mean "inode", you never have other copies. inodes are unique.
If by "file" you mean "pathname", then it's OK to delete a pathname to an inode that's still reachable by other pathnames. As long as any pathname reaches it, the inode remains, the other pathnames still reach it, and no data is lost.
But if the backup you're deleting contains the only remaining pathname to a given inode, then yeah, it's time to delete the inode, because an inode that can no longer be reached is just wasting disk space.
BTW: this tells you how to protect any particular version of file from being purged from backup. Just make a hard link to it, putting the hard link anywhere outside the backup folder. Time Machine let's the normal hard link counting mechanism determine when to delete the inode. Your hard link bumps the link count, and TM can never get it back down to zero.
One drawback is that the inode carries all security with it, including the "group:everyone deny delete" ACL that TM slaps on everything it backs up. You won't be able to easily unlink your new hard link.
Another is that it isn't easy to protect an entire folder this way. HFS+ allows hard links to folders, but I don't know of any unix command line tool that does. You'd probably have to write your own tool in C. (Or some kind soul will chime in and tell us which command to use.)
Soft links won't work. A soft link doesn't bump the link count of the target, so it breaks when the target pathname goes away (even if the target's inode doesn't).
). 