[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1710: Magic Folder: implement "Water Dragons" section of design doc

[Tahoe-LAFS]

#1710: Magic Folder: implement "Water Dragons" section of design doc
-------------------------------------+-------------------------------------
     Reporter:  davidsarah           |      Owner:  daira
         Type:  enhancement          |     Status:  assigned
     Priority:  normal               |  Milestone:  1.11.0
    Component:  code-frontend-       |    Version:  1.9.1
  magic-folder                       |   Keywords:  unlink space-efficiency
   Resolution:                       |  gc otf-magic-folder-objective4
Launchpad Bug:                       |
-------------------------------------+-------------------------------------

Comment (by daira):

 Replying to [comment:45 meejah]:
 > the case I have a fix for is: on say "bob's" side if "alice" deletes:
 the downloader downloads a "delete", so moves the file to "whatever.tmp"

 Do you mean "whatever.backup"? Nothing should ever be moved to
 "whatever.tmp".

 In any case, the IN_MOVED_FROM event for "whatever" should be ignored as
 described in comment:42. (The IN_MOVED_TO event should also be ignored
 because it's for an ignorable filename pattern.)

 > but immediately bob's uploader gets an inotify for the moved file, and
 when that gets processed it uploads another version (with delete=True) --
 but so then if "alice" now replaces the file, bob doesn't download it
 because the versions match.

 Yes, this sounds like the same case that I was talking about. It isn't a
 problem that Bob's uploader gets an inotify event, but that event should
 be ignored because Bob's db should already have been updated with metadata
 showing that the file has been deleted.

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