#2882 closed defect

Magic-folder uploads/downloads do not preserve filesystem metadata — at Version 4

Reported by: cypher Owned by:
Priority: major Milestone: undecided
Component: code-frontend-magic-folder Version: 1.12.1
Keywords: magic-folder metadata Cc:
Launchpad Bug:

Description (last modified by meejah)

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?)

Change History (4)

comment:1 Changed at 2017-06-22T05:38:19Z by cypher

  • Description modified (diff)

comment:2 Changed at 2017-06-22T14:23:26Z by cypher

  • Keywords metadata added

comment:3 Changed at 2017-09-19T19:40:19Z by cypher

  • Priority changed from normal to major

comment:4 Changed at 2018-01-05T00:27:08Z by meejah

  • Description modified (diff)

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.

Note: See TracTickets for help on using tickets.