ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-02-22 10:20:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Docs for drop-upload on Windows.

Browse Source 
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2015-04-28 20:11:40 +01:00 committed by Brian Warner
parent 61b3a9cef2
commit 54371547db
2 changed files with 28 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/configuration.rst
View File

@ -461,9 +461,10 @@ SFTP, FTP
Drop-Upload Drop-Upload
As of Tahoe-LAFS v1.9.0, a node running on Linux can be configured to As of Tahoe-LAFS v1.9.0, a node running on Linux or Windows can be
automatically upload files that are created or changed in a specified configured to automatically upload files that are created or
local directory. See :doc:`frontends/drop-upload` for details. changed in a specified local directory. See
:doc:`frontends/drop-upload` for details.
Storage Server Configuration Storage Server Configuration

38
docs/frontends/drop-upload.rst
View File

@ -14,17 +14,14 @@ Introduction
The drop-upload frontend allows an upload to a Tahoe-LAFS grid to be triggered The drop-upload frontend allows an upload to a Tahoe-LAFS grid to be triggered
automatically whenever a file is created or changed in a specific local automatically whenever a file is created or changed in a specific local
directory. This is a preview of a feature that we expect to support across directory. It currently works on Linux and Windows.
several platforms, but it currently works only on Linux.
The implementation was written as a prototype at the First International The implementation was written as a prototype at the First International
Tahoe-LAFS Summit in June 2011, and is not currently in as mature a state as Tahoe-LAFS Summit in June 2011, and is not currently in as mature a state as
the other frontends (web, CLI, SFTP and FTP). This means that you probably the other frontends (web, CLI, SFTP and FTP). This means that you probably
should not keep important data in the upload directory, and should not rely should not rely on all changes to files in the local directory to result in
on all changes to files in the local directory to result in successful uploads. successful uploads. There might be (and have been) incompatible changes to
There might be (and have been) incompatible changes to how the feature is how the feature is configured.
configured. There is even the possibility that it may be abandoned, for
example if unsolveable reliability issues are found.
We are very interested in feedback on how well this feature works for you, and We are very interested in feedback on how well this feature works for you, and
suggestions to improve its usability, functionality, and reliability. suggestions to improve its usability, functionality, and reliability.
@ -76,9 +73,8 @@ cause of any failures.
Known Issues and Limitations Known Issues and Limitations
============================ ============================
This frontend only works on Linux. There is an even-more-experimental This frontend only works on Linux and Windows. There is a ticket to add
implementation for Windows (`#1431`_), and a ticket to add support for support for Mac OS X and BSD-based systems (`#1432`_).
Mac OS X and BSD-based systems (`#1432`_).
Subdirectories of the local directory are not monitored. If a subdirectory Subdirectories of the local directory are not monitored. If a subdirectory
is created, it will be ignored. (`#1433`_) is created, it will be ignored. (`#1433`_)
@ -100,7 +96,7 @@ would be enough memory and bandwidth to efficiently perform them in parallel.
A drop-upload can occur in parallel with an upload by a different frontend, A drop-upload can occur in parallel with an upload by a different frontend,
though. (`#1459`_) though. (`#1459`_)
If there are a large number of near-simultaneous file creation or On Linux, if there are a large number of near-simultaneous file creation or
change events (greater than the number specified in the file change events (greater than the number specified in the file
``/proc/sys/fs/inotify/max_queued_events``), it is possible that some events ``/proc/sys/fs/inotify/max_queued_events``), it is possible that some events
could be missed. This is fairly unlikely under normal circumstances, because could be missed. This is fairly unlikely under normal circumstances, because
@ -108,6 +104,11 @@ the default value of ``max_queued_events`` in most Linux distributions is
16384, and events are removed from this queue immediately without waiting for 16384, and events are removed from this queue immediately without waiting for
the corresponding upload to complete. (`#1430`_) the corresponding upload to complete. (`#1430`_)
The Windows implementation might also occasionally miss file creation or
change events, due to limitations of the underlying Windows API
(ReadDirectoryChangesW). We do not know how likely or unlikely this is.
(`#1431`_)
Some filesystems may not support the necessary change notifications. Some filesystems may not support the necessary change notifications.
So, it is recommended for the local directory to be on a directly attached So, it is recommended for the local directory to be on a directly attached
disk-based filesystem, not a network filesystem or one provided by a virtual disk-based filesystem, not a network filesystem or one provided by a virtual
@ -136,9 +137,16 @@ file), then the old file is still present on the grid, and any other caps to
it will remain valid. See :doc:`../garbage-collection` for how to reclaim it will remain valid. See :doc:`../garbage-collection` for how to reclaim
the space used by files that are no longer needed. the space used by files that are no longer needed.
Unicode names are supported, but the local name of a file must be encoded Unicode filenames are supported on both Linux and Windows, but on Linux, the
correctly in order for it to be uploaded. The expected encoding is that local name of a file must be encoded correctly in order for it to be uploaded.
printed by ``python -c "import sys; print sys.getfilesystemencoding()"``. The expected encoding is that printed by
``python -c "import sys; print sys.getfilesystemencoding()"``.
On Windows, local directories with non-ASCII names are not currently working.
(`#2219`_)
On Windows, when a node has drop-upload enabled, it is unresponsive to Ctrl-C
(it can only be killed using Task Manager or similar). (`#2218`_)
.. _`#1105`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1105 .. _`#1105`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1105
.. _`#1430`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1430 .. _`#1430`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1430
@ -152,3 +160,5 @@ printed by ``python -c "import sys; print sys.getfilesystemencoding()"``.
.. _`#1710`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1710 .. _`#1710`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1710
.. _`#1711`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1711 .. _`#1711`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1711
.. _`#1712`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1712 .. _`#1712`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1712
.. _`#2218`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2218
.. _`#2219`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2219