docs/frontends/magic-folder.rst

   1 .. -*- coding: utf-8-with-signature -*-
   2
   3 ================================
   4 Tahoe-LAFS Magic Folder Frontend
   5 ================================
   6
   7 1.  `Introduction`_
   8 2.  `Configuration`_
   9 3.  `Known Issues and Limitations`_
  10
  11
  12 Introduction
  13 ============
  14
  15 The Magic Folder frontend allows an upload to a Tahoe-LAFS grid to be triggered
  16 automatically whenever a file is created or changed in a specific local
  17 directory. It currently works on Linux and Windows.
  18
  19 The implementation was written as a prototype at the First International
  20 Tahoe-LAFS Summit in June 2011, and is not currently in as mature a state as
  21 the other frontends (web, CLI, SFTP and FTP). This means that you probably
  22 should not rely on all changes to files in the local directory to result in
  23 successful uploads. There might be (and have been) incompatible changes to
  24 how the feature is configured.
  25
  26 We are very interested in feedback on how well this feature works for you, and
  27 suggestions to improve its usability, functionality, and reliability.
  28
  29
  30 Configuration
  31 =============
  32
  33 The Magic Folder frontend runs as part of a gateway node. To set it up, you
  34 need to choose the local directory to monitor for file changes, and a mutable
  35 directory on the grid to which files will be uploaded.
  36
  37 These settings are configured in the ``[magic_folder]`` section of the
  38 gateway's ``tahoe.cfg`` file.
  39
  40 ``[magic_folder]``
  41
  42 ``enabled = (boolean, optional)``
  43
  44     If this is ``True``, Magic Folder will be enabled. The default value is
  45     ``False``.
  46
  47 ``local.directory = (UTF-8 path)``
  48
  49     This specifies the local directory to be monitored for new or changed
  50     files. If the path contains non-ASCII characters, it should be encoded
  51     in UTF-8 regardless of the system's filesystem encoding. Relative paths
  52     will be interpreted starting from the node's base directory.
  53
  54 In addition:
  55  * the file ``private/magic_folder_dircap`` must contain a writecap pointing
  56    to an existing mutable directory to be used as the target of uploads.
  57    It will start with ``URI:DIR2:``, and cannot include an alias or path.
  58  * the file ``private/collective_dircap`` must contain a readcap
  59
  60 After setting the above fields and starting or restarting the gateway,
  61 you can confirm that the feature is working by copying a file into the
  62 local directory. Then, use the WUI or CLI to check that it has appeared
  63 in the upload directory with the same filename. A large file may take some
  64 time to appear, since it is only linked into the directory after the upload
  65 has completed.
  66
  67 The 'Operational Statistics' page linked from the Welcome page shows
  68 counts of the number of files uploaded, the number of change events currently
  69 queued, and the number of failed uploads. The 'Recent Uploads and Downloads'
  70 page and the node log_ may be helpful to determine the cause of any failures.
  71
  72 .. _log: ../logging.rst
  73
  74
  75 Known Issues and Limitations
  76 ============================
  77
  78 This frontend only works on Linux and Windows. There is a ticket to add
  79 support for Mac OS X and BSD-based systems (`#1432`_).
  80
  81 The only way to determine whether uploads have failed is to look at the
  82 'Operational Statistics' page linked from the Welcome page. This only shows
  83 a count of failures, not the names of files. Uploads are never retried.
  84
  85 The Magic Folder frontend performs its uploads sequentially (i.e. it waits
  86 until each upload is finished before starting the next), even when there
  87 would be enough memory and bandwidth to efficiently perform them in parallel.
  88 A Magic Folder upload can occur in parallel with an upload by a different
  89 frontend, though. (`#1459`_)
  90
  91 On Linux, if there are a large number of near-simultaneous file creation or
  92 change events (greater than the number specified in the file
  93 ``/proc/sys/fs/inotify/max_queued_events``), it is possible that some events
  94 could be missed. This is fairly unlikely under normal circumstances, because
  95 the default value of ``max_queued_events`` in most Linux distributions is
  96 16384, and events are removed from this queue immediately without waiting for
  97 the corresponding upload to complete. (`#1430`_)
  98
  99 The Windows implementation might also occasionally miss file creation or
 100 change events, due to limitations of the underlying Windows API
 101 (ReadDirectoryChangesW). We do not know how likely or unlikely this is.
 102 (`#1431`_)
 103
 104 Some filesystems may not support the necessary change notifications.
 105 So, it is recommended for the local directory to be on a directly attached
 106 disk-based filesystem, not a network filesystem or one provided by a virtual
 107 machine.
 108
 109 Attempts to read the mutable directory at about the same time as an uploaded
 110 file is being linked into it, might fail, even if they are done through the
 111 same gateway. (`#1105`_)
 112
 113 When a local file is changed and closed several times in quick succession,
 114 it may be uploaded more times than necessary to keep the remote copy
 115 up-to-date. (`#1440`_)
 116
 117 Files deleted from the local directory will not be unlinked from the upload
 118 directory. (`#1710`_)
 119
 120 The ``private/magic_folder_dircap`` and ``private/collective_dircap`` files
 121 cannot use an alias or path to specify the upload directory. (`#1711`_)
 122
 123 Files are always uploaded as immutable. If there is an existing mutable file
 124 of the same name in the upload directory, it will be unlinked and replaced
 125 with an immutable file. (`#1712`_)
 126
 127 If a file in the upload directory is changed (actually relinked to a new
 128 file), then the old file is still present on the grid, and any other caps to
 129 it will remain valid. See `docs/garbage-collection.rst`_ for how to reclaim
 130 the space used by files that are no longer needed.
 131
 132 Unicode filenames are supported on both Linux and Windows, but on Linux, the
 133 local name of a file must be encoded correctly in order for it to be uploaded.
 134 The expected encoding is that printed by
 135 ``python -c "import sys; print sys.getfilesystemencoding()"``.
 136
 137 On Windows, local directories with non-ASCII names are not currently working.
 138 (`#2219`_)
 139
 140 On Windows, when a node has Magic Folder enabled, it is unresponsive to Ctrl-C
 141 (it can only be killed using Task Manager or similar). (`#2218`_)
 142
 143 .. _`#1105`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1105
 144 .. _`#1430`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1430
 145 .. _`#1431`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1431
 146 .. _`#1432`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1432
 147 .. _`#1433`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1433
 148 .. _`#1440`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1440
 149 .. _`#1449`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1449
 150 .. _`#1458`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1458
 151 .. _`#1459`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1459
 152 .. _`#1710`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1710
 153 .. _`#1711`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1711
 154 .. _`#1712`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1712
 155 .. _`#2218`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2218
 156 .. _`#2219`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2219
 157
 158 .. _docs/garbage-collection.rst: ../garbage-collection.rst
 159