Changes between Initial Version and Version 1 of Ticket #2882, comment 5
- Timestamp:
- 2018-01-05T19:22:26Z (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #2882, comment 5
initial v1 10 10 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.. 11 11 12 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 a nend-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.12 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 a solitary 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. 13 13 14 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).14 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'") and/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). 15 15 16 16 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).
