[tahoe-dev] [tahoe-lafs] #924: stop writing mtime and ctime fields (except for "tahoe backup")
tahoe-lafs
trac at allmydata.org
Thu Jan 21 21:07:36 PST 2010
#924: stop writing mtime and ctime fields (except for "tahoe backup")
------------------------------------------------------------------------------------+
Reporter: zooko | Owner: warner
Type: enhancement | Status: new
Priority: major | Milestone: eventually
Component: code-dirnodes | Version: 1.5.0
Keywords: backward-compatibility forward-compatibility unix windows tahoe-backup | Launchpad_bug:
------------------------------------------------------------------------------------+
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 [source:docs/frontends/webapi.txt at 4112#L552 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.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/924>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list