#2427 closed defect (fixed)

Magic Folder on Linux: handle case when directory is removed from monitored directory

Reported by: dawuud Owned by: dawuud
Priority: normal Milestone: 1.12.0
Component: code-frontend-magic-folder Version: 1.10.0
Keywords: test-needed otf-magic-folder-objective4 Cc:
Launchpad Bug:

Description (last modified by daira)

We need to handle the case where a directory is removed or moved out of the monitored local directory.

Specifically this case needs to be specially handled only when the sub-directory was moved into the drop uploader directory and a inotify watch for that sub-directory was added. Further investigation is needed to determine the proper way to remove this inotify watch.

So far it seems that we will respond to either the IN_DELETE_SELF or IN_MOVE_SELF events for each of these sub-directory inotify "watches".

Change History (17)

comment:1 Changed at 2015-05-23T18:49:33Z by daira

It seems as though the IN_EXCL_UNLINK flag would help with this:

   IN_EXCL_UNLINK (since Linux 2.6.36)
          By default, when watching events on the children of a
          directory, events are generated for children even after
          they have been unlinked from the directory.  This can
          result in large numbers of uninteresting events for some
          applications (e.g., if watching /tmp, in which many
          applications create temporary files whose names are
          immediately unlinked).  Specifying IN_EXCL_UNLINK changes
          the default behavior, so that events are not generated for
          children after they have been unlinked from the watched
          directory.

comment:2 Changed at 2015-05-24T14:37:45Z by daira

The constant for IN_EXCL_UNLINK isn't defined by Twisted (https://twistedmatrix.com/trac/ticket/7789) but that's okay, we can define it ourselves, since Twisted passes through unknown flags.

comment:3 Changed at 2015-05-24T16:55:10Z by daira

  • Keywords drop-upload unix added

Note that this is not an issue on Windows, because ReadDirectoryChangesW only reads events that occur for paths that are still under the recursively-watched directory.

comment:4 Changed at 2015-05-24T16:55:29Z by daira

  • Component changed from unknown to code-frontend-drop-upload
  • Milestone changed from undecided to 1.11.0

comment:5 Changed at 2015-05-24T16:56:21Z by daira

  • Summary changed from handle case when directory is removed from drop upload directory to drop-upload on Linux: handle case when directory is removed from drop upload directory

comment:6 Changed at 2015-05-26T09:54:26Z by daira

  • Keywords test-needed added
  • Owner changed from daira to dawuud

comment:7 Changed at 2015-05-26T18:28:03Z by dawuud

Furthermore these additional tests should also demonstrate that a directory which has been moved into the drop upload directory will have the IN_EXCL_UNLINK behavior just like the upload directory itself.

comment:8 Changed at 2015-06-01T16:11:09Z by daira

  • Keywords magic-folder added

Add magic-folder keyword to all drop-upload tickets.

comment:9 Changed at 2015-06-01T16:54:54Z by daira

  • Description modified (diff)
  • Keywords otf-magic-folder-objective4 added; drop-upload unix magic-folder removed
  • Summary changed from drop-upload on Linux: handle case when directory is removed from drop upload directory to Magic Folder on Linux: handle case when directory is removed from monitored directory

comment:10 Changed at 2015-06-03T20:04:10Z by dawuud

I'm a little tiny bit frustrated trying to debug the unit tests. They seem to be written correctly but are producing unexpected results. Perhaps we've overlooked a simple and silly mistake somewhere.

I've pushed a commit to my dev branch which demonstrates some broken behavior; a directory with a file (small_tree) is moved into the upload directory. The directory and file are uploaded... however when an additional file is written to the subdir... it is not uploaded. So confusing!

https://github.com/david415/tahoe-lafs/tree/2427.remove-uploader-watch.1

comment:11 Changed at 2015-06-03T20:04:24Z by dawuud

  • Owner changed from dawuud to daira

comment:12 Changed at 2015-06-03T22:01:53Z by daira

  • Owner changed from daira to dawuud

Remember that we removed the autoAdd=True argument from the initial call to watch, in https://github.com/david415/tahoe-lafs/commit/e57645a9f15a7223eb33984cdd495a55b246e474. We did this because we believed that adding the extra explicit call to watch in _add_dir (here) was the correct way to handle directories being moved into the monitored directory tree, since we had found that autoAdd does not implicitly add a watch in that case.

It's likely that the problem is in that code; I would suggest adding a print to make sure that watch is being called for the moved-in directory, and with the correct arguments.

Last edited at 2015-06-03T22:05:20Z by daira (previous) (diff)

comment:13 Changed at 2015-06-03T23:31:38Z by dawuud

yess! i got the real tests passing in my dev branch but i'll have to fix the mock tests later tomorrow.

comment:14 Changed at 2015-06-04T10:15:23Z by daira

\o/. Looking forward to seeing what the problem was.

comment:15 Changed at 2015-06-04T23:45:59Z by dawuud

the problem was that i accidentally had some important code bits commented out... and the original problem was solved by our not using the autoadd feature. fixed here: https://github.com/david415/tahoe-lafs/commits/2427.remove-uploader-watch.1 https://github.com/david415/tahoe-lafs/commit/fe797eb76b88d3e31da842551b2abe2d5084b6e6

comment:16 Changed at 2015-06-11T16:32:53Z by daira

  • Resolution set to fixed
  • Status changed from new to closed

Fixed on the 2438.otf-objective-4.2 branch.

comment:17 Changed at 2016-03-22T05:02:52Z by warner

  • Milestone changed from 1.11.0 to 1.12.0

Milestone renamed

Note: See TracTickets for help on using tickets.