#1050 closed defect (fixed)
open with SSH_FXF_TRUNC without SSH_FXF_CREAT violates SFTP spec, but everyone does it anyway
Reported by: | bj0 | Owned by: | bj0 |
---|---|---|---|
Priority: | major | Milestone: | 1.7.0 |
Component: | code-frontend-ftp-sftp | Version: | 1.6.1 |
Keywords: | sftp standards sshfs | Cc: | |
Launchpad Bug: |
Description (last modified by warner)
It apparrently is against the SFTP spec (but not the POSIX) to open a file with SSH_FXF_TRUNC without including SSH_FXF_CREAT.
Programs like OpenSSH server and sshfs ignore this little detail, though, and programs like "cp" fail if it is followed.
workaround: SFTP frontend should accept FXF_WRITE | FXF_TRUNC.
Change History (12)
comment:1 Changed at 2010-05-19T04:17:20Z by davidsarah
- Component changed from unknown to code-frontend
- Keywords sftp standards sshfs added
- Milestone changed from undecided to 1.7.0
- Owner changed from nobody to davidsarah
- Status changed from new to assigned
comment:2 Changed at 2010-05-19T06:04:11Z by bj0
the SFTP frontend now accepts WRITE | TRUNC, so
cp file1 file2
works.
but doing:
cat file1 > newfile
or
cat file1 >> newfile
when newfile doesn't already exist fails with a:
bash: newfile: No such file or directory
it does create a 'newfile' file, but it has zero length. (and repeating the command will succeed on the existing file)
from strace, it appears to be opening 'newfile' with the flags WRITE | CREAT | TRUNC.
comment:3 Changed at 2010-05-20T04:56:35Z by davidsarah
- Keywords review-needed added
The problem in comment:2 is due to the shell assuming that newfile already exists just after the open call. It does a stat which causes a getAttrs request, which fails with NoSuchChildError (FX_NO_SUCH_FILE). Then newfile is closed, but nothing has been written to it, so it is zero-length.
The ticket1037 branch has been changed to keep track of which paths correspond to open files. This allows us to return fake attributes from the getAttrs request (without having to write a zero-length file on the open call). zooko: please review this changeset, and bj0: please pull and re-test.
comment:4 Changed at 2010-05-20T05:00:45Z by davidsarah
- Owner changed from davidsarah to bj0
- Status changed from assigned to new
Please also test 'touch newfile' before and after pulling the changes. Based on https://bugzilla.gnome.org/show_bug.cgi?id=522532 , I think it might have the same issue.
comment:5 Changed at 2010-05-20T07:14:00Z by bj0
- Keywords review-needed removed
I just checked and
touch newfile
Does work before the latest patches, although it takes like 20s before the new file appears in ls
After the patch, it shows up in ls instantly. Also:
cat test2 > newfile
works.
comment:6 follow-up: ↓ 8 Changed at 2010-05-20T16:01:47Z by davidsarah
Thanks for the testing.
The current code is not quite right: it indexes the global_open_files dict by canonical path, but this does not include the root node. So, paths for different user accounts could be confused. It should instead index by the directory entry, i.e. parent cap and child name.
The test coverage also needs to be improved to cover cases where the same directory entry is opened more than once, and where files are still open when a connection is logged out.
comment:7 Changed at 2010-05-20T16:03:14Z by davidsarah
- Owner changed from bj0 to davidsarah
- Status changed from new to assigned
comment:8 in reply to: ↑ 6 Changed at 2010-05-22T04:22:51Z by davidsarah
Replying to davidsarah:
The current code is not quite right: it indexes the global_open_files dict by canonical path, but this does not include the root node. So, paths for different user accounts could be confused. It should instead index by the directory entry, i.e. parent cap and child name.
This is now fixed. Also, we now try to support renaming immutable files that have been opened for writing or creation, while they are still open. Many apps depend on this: they create a temporary file, rename it to the destination file, and then close it.
bj0: please re-test both the previous tests, and saving files with gedit and OpenOffice?.
comment:9 Changed at 2010-05-25T04:20:02Z by bj0
I tried, and got no errors with: cp mv cat > cat >> gedit OpenOffice?
gedit and OO both saved fine it seemed.
One odd thing i noticed was that when i open a file with vi, then close it, the .swp file isn't deleted. I took a quick look at the flog and it looks like it called removeFile and got a SUCCESS, but the file is still there.
comment:10 Changed at 2010-06-08T03:34:12Z by davidsarah
- Owner changed from davidsarah to bj0
- Status changed from assigned to new
Assigning to bj0 to check whether the remaining bug in comment:9 still exists. (It should have been fixed by the changes to handle remove/close race conditions.)
comment:11 Changed at 2010-06-12T23:48:13Z by davidsarah
- Resolution set to fixed
- Status changed from new to closed
Fixed according to bj0 on IRC.
comment:12 Changed at 2017-02-05T17:41:37Z by warner
- Component changed from code-frontend to code-frontend-ftp-sftp
- Description modified (diff)
See http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-6.3 for the relevant specification of FXF_TRUNC and FXF_CREAT, and http://www.opengroup.org/onlinepubs/000095399/functions/open.html for the POSIX open call.
sshfs appears to just pass the POSIX flags along with the obvious mappings.