directory listing bug

[Imported from Trac: page SftpFrontend, version 30]
davidsarah 2010-06-13 16:45:30 +00:00
parent 0f95505b75
commit 7cd48a62ff

@ -13,12 +13,15 @@ In practice, that means you can run the Tahoe-LAFS gateway locally on the same m
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 close timeout of 15 seconds. 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 close timeout of 15 seconds.
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. 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 [FTP-and-SFTP.txt]source:docs/frontends/FTP-and-SFTP.txt for information on how the SFTP frontend treats immutable and mutable files. See the last section of [FTP-and-SFTP.txt]source:docs/frontends/FTP-and-SFTP.txt for information on how the SFTP frontend treats immutable and mutable files.
The '`ctime`' and '`mtime`' fields will not be updated when a mutable file is changed, and do not have exactly the semantics specified by POSIX in other cases. The '`ctime`' and '`mtime`' fields will not be updated when a mutable file is changed, and do not have exactly the semantics specified by POSIX in other cases.
### sshfs ### sshfs
sshfs is an SFTP client that allows filesystem access via FUSE (a user-space filesystem layer). It works on Linux and other Unix systems that provide FUSE. For Mac OS X, a patched version of sshfs is included as part of [MacFUSE](http://code.google.com/p/macfuse/). sshfs is an SFTP client that allows filesystem access via FUSE (a user-space filesystem layer). It works on Linux and other Unix systems that provide FUSE. For Mac OS X, a patched version of sshfs is included as part of [MacFUSE](http://code.google.com/p/macfuse/).