#1433 closed enhancement (fixed)

drop-upload: also monitor subdirectories

Reported by: davidsarah Owned by: daira
Priority: major Milestone: 1.12.0
Component: code-frontend-magic-folder Version: 1.8.2
Keywords: drop-upload usability otf-magic-folder-objective2 Cc:
Launchpad Bug:

Description (last modified by warner)

The prototype implementation of drop-upload in #1429 monitors only a single directory, and ignores creation of subdirectories or changes to files within them. It is possible to monitor subdirectories as well, although the efficiency and complexity of this varies depending on the design of the platform's filesystem monitoring API (if we support multiple platforms with this feature as suggested in #1431 and #1432).

Change History (20)

comment:1 Changed at 2011-07-25T12:26:58Z by davidsarah

  • Type changed from defect to enhancement

comment:2 Changed at 2014-12-02T19:47:01Z by warner

  • Component changed from code-frontend to code-frontend-drop-upload
  • Description modified (diff)

comment:3 Changed at 2015-03-12T23:52:08Z by daira

  • Keywords otf-magic-folder added

comment:4 Changed at 2015-04-02T14:54:26Z by daira

  • Keywords otf-magic-folder-objective2 added; otf-magic-folder removed

comment:5 Changed at 2015-04-10T12:28:06Z by daira

Note that the IN_ONLYDIR constant in the current event mask doesn't do what you might think it does. It only ensures that the root being monitored is a directory.

comment:6 Changed at 2015-04-10T20:01:04Z by daira

On 07/04/15 21:05, David Stainton wrote:>

a couple of my initial and trife observations: 1. Looks like the latest Twisted inotify class has got a recursive watch. I'm not saying we need to use that version of Twisted; it's a simple loop we can implement. https://twistedmatrix.com/trac/browser/tags/releases/twisted-15.0.0/twisted/internet/inotify.py#L350

This has been there since the inotify support was added in Twisted 10.1.0, in fact.

2. I looked at the source code of the twisted INotify class to see if it's watch method could be called more than once and behave properly. It looks like it does support this usage.

Yes, it does, but the recursive/autoAdd support looks sufficient so we shouldn't need this. (We also don't need it for Windows because ReadDirectoryChangesW has a similar flag to watch a subdirectory tree.)

3. I am not clear on why drop_upload.py uses this inotify mask:

mask = inotify.IN_CLOSE_WRITE | inotify.IN_MOVED_TO | inotify.IN_ONLYDIR

Combining all these definitions: IN_MOVED_TO - File moved into watched directory IN_CLOSE_WRITE - File opened for writing was closed IN_ONLYDIR - Only watch pathname if it is a directory.

This means we only watch subdirectories that have been created or moved into the directory. Did I understand things correctly?

See comment:5 .

4. the inotify man page states:

If monitoring an entire directory subtree, and a new subdirectory is created in that tree, be aware that by the time you create a watch for the new subdirectory, new files may already have been created in the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch.

This obviously means we should construct a mask specifically to catch newly added directories like this:

mask = inotify.IN_MOVED_TO | inotify.IN_ONLYDIR

and then add a specific inotify watch for that subdirectory... AND add recursively add that directory and its contents to the upload queue.

The autoAdd flag already adds watches for children of newly added directories (and has done so since Twisted 10.1.0):

https://twistedmatrix.com/trac/browser/tags/releases/twisted-10.1.0/twisted/internet/inotify.py#L259

It also synthesizes IN_CREATE events for files and subdirectories found in those newly added directories (see the _addChildren method in inotify.py).

comment:7 Changed at 2015-04-11T00:03:50Z by dawuud

sounds like we need a simple one line change like this: https://github.com/david415/tahoe-lafs/tree/david-1433-1

Does this satisfy our spec?: https://github.com/tahoe-lafs/tahoe-lafs/blob/master/docs/proposed/magic-folder/filesystem-integration.rst

which states that we need to do a full scan of new directories...

I am wondering what would happen if a user moved a directory tree into the magic folder? Would the subdirectories be scanned? It looks like to me they would not be. If this is the case then maybe we'll have to not use the autoAdd feature.

Last edited at 2015-04-11T00:28:02Z by dawuud (previous) (diff)

comment:8 Changed at 2015-04-11T01:38:15Z by daira

The spec says that a scan of new directories needs to be done, it doesn't say what code is responsible for that. At the time, I hadn't looked at the relevant Twisted code.

We do need to check what happens in the move-one-directory-into-another case. I suspect it Just Works though, since _addChildren doesn't distinguish that case, and shouldn't need to.

comment:9 Changed at 2015-04-11T01:39:36Z by daira

I suggest first writing tests for these cases, rather than worrying about the implementation.

comment:10 Changed at 2015-04-12T22:32:28Z by daira

  • Milestone changed from undecided to 1.11.0

comment:11 Changed at 2015-04-15T16:59:41Z by dawuud

i added some code to david-1433-1 branch that handles the symlink and directory cases.

if symlink then ignore file and print error to the log. if dir then create the subdirectory.

comment:13 Changed at 2015-04-18T16:37:40Z by daira

  • Keywords review-needed added
  • Owner set to daira
  • Status changed from new to assigned

Excellent! Will review now.

comment:14 Changed at 2015-04-24T07:08:07Z by dawuud

Ok recently fixed some problems with these tests... and I think it exposes a bug... must look into it...

comment:15 Changed at 2015-04-28T17:49:06Z by dawuud

fixed unit tests and code. awaiting code review from daira for my recent changes regarding the addition of a notifier watch upon directory placement in the uploader directory. (the watch is recursive and a recursive scan of the new directory is also applied)

comment:16 Changed at 2015-04-28T23:47:09Z by daira

I reviewed this (and we made a few other fixes in our Tuesday pairing session); it looks good. I still need to review the rest of the queue/scanning code.

Last edited at 2015-04-28T23:47:23Z by daira (previous) (diff)

comment:17 Changed at 2015-05-02T16:42:02Z by daira

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

comment:18 Changed at 2015-05-02T16:44:00Z by daira

Closing this and using ticket #2406 for any further review comments.

comment:19 Changed at 2015-05-02T16:45:15Z by daira

  • Keywords review-needed removed

comment:20 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.