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

Tahoe-LAFS trac at tahoe-lafs.org
Fri Jan 5 19:08:30 UTC 2018


#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:           |
-------------------------+-----------------------------------

Comment (by cypher):

 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)

 Yes, you're completely right. My bad; I'm not sure why I even included
 "uid/gid" here originally.. I'll remove that from the ticket..


   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?

 Not from our sessions, no, however this is a great question that certainly
 warrants further exploration and user-testing..

 For what it's worth, other file-sync applications that I've used/tried in
 the past (Dropbox, Seafile, Syncthing) have indeed preserved/propagated
 the mtime of the original file (i.e., setting mtime to "when Alice updated
 the file" instead of "when $APPLICATION updated the file") such that when
 I originally tried magic-folder I was surprised and disappointed to learn
 that it did not work the same way (and could not use it because I depended
 heavily on mtime to provide additional time/date context for academic
 research notes, in-progress papers, student assignments, etc.). Because of
 this, for most of my use-cases, I'd rather use `rsync -a` to synchronize
 directories across machines than magic-folder. Obviously my own needs
 don't necessarily reflect those of others but I'd be very
 curious/interested to hear additional perspectives on what the preferred
 /least-surprising usage should be..

 It is worth probably pointing out, however, that there's a major
 difference in expectations between the single-user case (i.e., Bob syncing
 a folder from his desktop to his laptop) vs. the multi-user case (i.e.,
 Bob syncing a folder from his laptop to Alice's). I'd argue that, in the
 single-user case, knowing when *magic-folder* updated my files is largely
 irrelevant: I already know that I am the only person editing the files and
 so I would much rather have the metadata on my machines reflect the record
 of *my* own actions -- not the actions of magic-folder (which I, as an
 end-user, don't really care about); the "Documents" folder on my laptop
 should magically look and work just like the "Documents" folder on my
 desktop (and this includes being able to be sorted in the same way). If,
 for some reason, I ever really need to know when magic-folder updated it,
 I can/should be able get that information from magic-folder/tahoe itself.

 Admittedly, the multi-user scenario is more complicated, but I'm not still
 not convinced that setting the mtime for a given file to when *magic-
 folder* updated it is really what I (as a non-technical end-user) would
 want. When collaborating with others, what I really want to know (in a
 broader knowledge sense) is *that* somebody who is not me made some change
 to a shared folder/file (and, ideally, *who* that person is, if that
 information can be provided). mtimes alone, obviously, do not provide this
 sort of information; an `ls -l` by itself can't tell me whether it was
 *magic-folder* that made a change or some other application on my
 computer, or whether it was me who made the change or some other person
 (which are all, arguably, important pieces of information in multi-
 user/shared situations). That said, in the multi-user situation, what I
 probably really want is an immediate notification telling me that a file
 was updated (e.g., "Alice updated 'Proposal.doc'") wand/or the ability to
 see a log/listing of such events should I need it later (e.g., via the
 CLI, WUI, or something like Gridsync). Dropbox and Seafile both work
 roughly in this way (though they both have stronger, "account"-centric
 notions of identity in comparison to magic-folder).

 All that being said, I guess my overall point here is that if the end-
 user's goal is to know when $APPLICATION updates a file, they should get
 that information from $APPLICATION itself; we should not rely on
 filesystem timestamps to provide a record of this information since doing
 so is neither reliable nor convenient for this purpose (and, as suggested
 above, in some cases, altering mtimes in such a way or having them mean
 something different in comparison to other applications can become
 confusing or inconvenient).

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


More information about the tahoe-lafs-trac-stream mailing list