is not at all how I view the purpose of the project, simply because I am not using it in a business context. From a business perspective, ownCloud is promising as a competitor to services like Dropbox and Google Drive, which helps the business regain control over their data and perhaps even enhance their ability to track and monitor the activity of employees. This is why ownCloud has a commercial side through which I hope they will make massive profits from their efforts.an application used to limit and track the flow of files within a group or organization
General compatibility issues
Before uploading a file to a Tahoe filesystem, the whole file has to be available. This means that the upload can only start when the file has been closed in the SFTP session. Particularly when writing large files, the client may time out between sending the close request and receiving the response (ticket #1041). This is known to be a problem for at least the WinSCP client, which has a default close timeout of 15 seconds. In the case of WinSCP this can be worked around by setting WinSCP -> Connection -> Timeouts to 6000 seconds (the maximum allowed); other clients with this problem may have similar settings.
In the period after the close but before the upload has finished, the closed file may not appear in directory listings, or may appear with an incorrect modification time.
Since Tahoe uses capability access control rather than Unix-style permissions, the permission bits seen by SFTP clients are only an approximation chosen to avoid confusing client programs. In particular the 'user', 'group' and 'world' permissions on a Tahoe file will always be the same. It is possible to clear all of the 'w' bits on a file, which will prevent that file from being opened for writing, but note that its directory entry can still be replaced via a write cap to the directory.
See the last section of docs/frontends/FTP-and-SFTP.rst for information on how the SFTP frontend treats immutable and mutable files.
Deleting a directory via the SFTP frontend will not check that it is empty. The directory will be unlinked from its parent, but its contents will remain accessible via any other capabilities to it.
The 'ctime' and 'mtime' attributes will always be the same, and are set from the Tahoe linkmotime timestamp, which is changed only when the link from the parent directory is modified (see the 'About the metadata' section of webapi.rst). These fields are not updated when the contents of a mutable file are changed. The SFTP protocol and the server are able to represent dates up to the year 2106, but some clients may print dates incorrectly after 2037.
Versions of Twisted before v11.0 have a bug in support for rekeying. Tahoe-LAFS v1.10.0 requires a later version of Twisted and so will not be affected by this problem. For earlier versions of Tahoe-LAFS, it is recommended to install a version of Twisted between v11.0 and v12.2 inclusive (and use tahoe --version to check that it is being used); otherwise, this bug might cause a hang or 100% CPU usage by the gateway when a client tries to rekey. Depending on the client, rekeying may be triggered based on a time interval or the amount of data sent (for example, 1 GiB to 4 GiB for the openssh client), so this problem may not happen immediately when testing.
Version v12.3 of Twisted is incompatible with the SFTP frontend (#1926, #1525). Upgrade to Tahoe-LAFS v1.10.0 to fix this problem.
Users browsing this forum: Baidu [Spider], Google [Bot] and 18 guests