stop writing mtime and ctime fields (except for "tahoe backup")

[zooko]

In Tahoe-LAFS v1.3 metadata fields named mtime and ctime were written onto links both by "tahoe backup" and by any operation which created or updated a link. In Tahoe-LAFS v1.4 we started putting data with clarified semantics in fields named linkmotime and linkcrtime in a sub-dict of the link metadata named tahoe.

For backwards compatibility, we continued to write mtime and ctime into the original fields whenever a link was This situation, piled on top of the ambiguity and mistakes inherent in Python's notion of "ctime" (see #628 and #897) led to a rather complicated semantics for the mtime and ctime fields. Interpreting what a ctime field means require both figuring out whether "tahoe backup" or a different operation was the last operation to touch that link as well as whether that operation was running on Windows or another operating system. See the doc about those fields which takes up 86 lines in webapi.txt.

In some future release of Tahoe-LAFS (for example, maybe Tahoe-LAFS v1.7) we should make it so that normal link creations or updates (i.e., excluding the "tahoe backup" command) no longer write to the old mtime and ctime fields, but only to the new tahoe:linkmotime and tahoe:linkcrtime fields.

This will greatly simplify the semantics of mtime and ctime -- they will then mean only what "tahoe backup" intends them to mean (see #897 for what that is), provided that only new clients (>= v1.7) have ever written to them. (Hm, that suggests that "tahoe backup" ought to choose new names, such as creating a new sub-dict named backup or original-file-metadata, containing keys named something like mtime and posix-change-time and creation-time, and we should abandon the old mtime completely...)

This will mean that Tahoe-LAFS v1.3 clients which examine those directories will not see any mtime or ctime info but they will still be able to use the links to access file contents.

[zooko]

I wrote in the original ticket description:

(Hm, that suggests that "tahoe backup" ought to choose new names, such as creating a new sub-dict named backup or original-file-metadata, containing keys named something like mtime and posix-change-time and creation-time, and we should abandon the old mtime completely...)

Oh wait, I'm wrong about that because we are not planning (per #897) to change "tahoe backup"'s semantics of mtime. We are planning to change its semantics of creation-time and change-time, but we are also planning in #897 to give those two concepts new names and stop writing them into ctime, so there's no need to move the other fields into a new sub-dict or rename them.

[zooko]

The places where we are still setting mtime and ctime and we would like to stop are in Adder.modify().

[zooko]

Brian: would you object to me doing this for v1.7.0? (Not that I'm likely to have time after more urgent things like fixing packaging problems.)

[davidsarah]

This patch changes the SFTP frontend to set its POSIXish 'ctime' attribute from tahoe:linkmotime, not from any 'ctime' field in the metadata

[zooko]

Applied the sftp patch as c1412c8a81aa395d.

[davidsarah]

dirnode.py: stop writing 'ctime' and 'mtime' fields. Includes documentation and test changes. (The doc needs to be changed slightly if we don't commit this for 1.7.0.)

[davidsarah]

Why I'd like this patch to go into 1.7.0:

In 1.6.1, mtime and ctime were only set automatically when a link is created, or when it is updated with no metadata. This was inconsistent with the documentation in source:docs/frontends/webapi.txt4236#L659 , so in 1.7beta, it was changed (by 4f58355a0eebd79e) to always update mtime and ctime. If we don't want those fields to be updated automatically, then it would be better not to have to explain that the behaviour changed in 1.7 and then again in 1.7.1.

[zooko]

Okay, I'm convinced! Let's put this in 1.7.0 now. Oh look, you already accidentally did! ;-) 471287519385facb

[davidsarah]

Why not writing mtime and ctime should be compatible with tahoe backup:

If we update a link to a file after it has been written by 'tahoe backup', then the previous behaviour would be that 'tahoe backup' would treat the file as more up-to-date. That's wrong because it isn't necessarily up-to-date with the contents of the file on the local system. Not writing 'ctime' and 'mtime' can only cause a backup run to be more likely to backup the file, which should be harmless in terms of correctness.

[davidsarah]

Some tests missed in 471287519385facb were corrected in a2caf6f4b22fe02f.