"tahoe backup" and HFS+ OS-level immutable directories: copying Time Machine backups

[warner]

Some local filesystems offer immutable directories (specifically HFS+, as created by apple's Time Machine backup tool). If the "tahoe backup" command were able to recognize these, it could run faster, by remembering that it had already made a copy of the local directory, and refraining from making a new copy each time.

This probably requires a test like:

• if local filesystem is HFS+, and
• use some extended OS API calls to find out if the directory is immutable
• then read devno and inodeno, then map into the dircache table of the backupdb

We need to learn more about how immutable directories work on HFS+, to see what sorts of consistent identifiers can be used (I don't know if inodeno is appropriate, or even available).

This would be useful to do e.g. "tahoe backup /Volume /TMBackupDrive/Latest tahoe:somewhere". When nothing had changed, the local disk IO would be reduced to a single directory read. (the current code would need to read the contents of every directory in the system, before being able to determine that the previously-uploaded directories could be re-used).

[davidsarah]

If you use os.[f]stat on an immutable file or directory, st_flags should include stat.SF_IMMUTABLE (I think, based on some googling; I haven't tested it). This is not specifically an HFS+ or OS-X'ism; in principle it could be supported on any POSIX-like system.

[davidsarah]

Actually the immutable flag is either stat.SF_IMMUTABLE or stat.UF_IMMUTABLE, depending on whether a superuser or non-superuser has set it.

[davidsarah]

Although HFS+ does support SF,UF_IMMUTABLE, apparently that's not what Time Machine uses to make backups read-only. According to ​http://www.318.com/techjournal/general-technology/the-time-machine-safety-net/ , it uses ACLs to do that.