[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2882: Magic-folder uploads/downloads do not preserve filesystem metadata

[Tahoe-LAFS]

#2882: Magic-folder uploads/downloads do not preserve filesystem metadata
-------------------------+-----------------------------------
     Reporter:  cypher   |      Owner:
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  unknown  |    Version:  1.12.1
   Resolution:           |   Keywords:  magic-folder metadata
Launchpad Bug:           |
-------------------------+-----------------------------------

Old description:

> Unlike the `tahoe backup` command, magic-folder uploads/downloads do not
> preserve filesystem metadata (such as mtime/ctime, uid/gid, file
> attributes, etc.); when Bob's shared magic-folder downloads a file
> uploaded by Alice, that file's mtime/ctime will be set to the time at
> which the download completed rather than the (arguably more desirable)
> times at which that file was originally modified/created on Alice's
> computer.
>
> Preserving this metadata would be desirable not only for traditional
> archival purposes (since, e.g., the date that users may have taken
> certain pictures or written certain documents is often important) but
> also for the purposes of aiding users to resolve conflicts produced by
> magic-folder itself in a collaborative scenario (since, e.g., with the
> current implementation, Bob has no straightforward way of knowing whether
> the conflicting file produced on his computer by Alice was the one she
> edited last week or this morning).

New description:

 Unlike the `tahoe backup` command, magic-folder uploads/downloads do not
 preserve filesystem metadata (such as mtime/ctime, uid/gid, file
 attributes, etc.); when Bob's shared magic-folder downloads a file
 uploaded by Alice, that file's mtime/ctime will be set to the time at
 which the download completed rather than the (arguably more desirable)
 times at which that file was originally modified/created on Alice's
 computer.

 Preserving this metadata would be desirable not only for traditional
 archival purposes (since, e.g., the date that users may have taken certain
 pictures or written certain documents is often important) but also for the
 purposes of aiding users to resolve conflicts produced by magic-folder
 itself in a collaborative scenario (since, e.g., with the current
 implementation, Bob has no straightforward way of knowing whether the
 conflicting file produced on his computer by Alice was the one she edited
 last week or this morning).

 (Also, maybe this should be an enhancement instead of defect?)

--

Comment (by meejah):

 I'm not convinced (trying to) preserve UID or GID is a good idea; these
 IDs will often vary between computers (even if the very same human set
 them up). Even if the same human did set them up, they'd probably want the
 symbolic names preserved/set (i.e. "alice" or "a_group" rather than the
 1000 or whatever).

 I *think* trying to preserve mtime should work, but we should double-check
 that magic-folder doesn't depend on these when searching for updates.
 *Can* we actually can mess with ctime directly..?

 A different reason people might look at the timestamps could be to answer
 the question "when did magic-folder update this file" rather than "when
 did Alice update this file"; do we have any real-user feedback indicating
 which one is least surprising?

 Consider an example: Alice adds a new file to her magic-folder that hasn't
 been modified for a year (but she happens to "cp" it into her magic
 directory). Thus, from Linux's perspective, the mtime will be "now" (while
 Alice might *except* it to be "a year ago" -- because she forgot to do "cp
 -a"). Which one does Bob want to see as "mtime"? (One of three choices:
 when his Tahoe client downloaded it; Alice's "now"; or "a year ago").

 We can't actually choose "a year ago" in the above example, because Alice
 accidentally destroyed that metadata. So, presuming she didn't (by using
 `cp -a`) then we could chose that as "the" answer.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2882#comment:4>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage