From: Joseph M L. <jo...@jo...> - 2006-02-23 04:03:36
|
Hello, I just tried sshfs for the first time today, and after some debugging have found a problem likely related to an old version of openssh. The server is sshd version OpenSSH_2.5.2p2 running on Redhat 7.1 (not mine!). After some debugging, I see sshfs sending a truncate command and receiving a successful response. However, the file remains unchanged on the remote end. I realize it's unlikely, but is there anything I can hack in place to make this work with such an old version of openssh? Thanks, Joe |
From: Miklos S. <mi...@sz...> - 2006-02-23 09:45:10
|
> I just tried sshfs for the first time today, and after some debugging > have found a problem likely related to an old version of openssh. > > The server is sshd version OpenSSH_2.5.2p2 running on Redhat 7.1 (not > mine!). > > After some debugging, I see sshfs sending a truncate command and > receiving a successful response. However, the file remains unchanged on > the remote end. > > I realize it's unlikely, but is there anything I can hack in place to > make this work with such an old version of openssh? Well, an ftruncate() to zero can be worked around with the following patch. Plain truncate() already has a workaround for this, so removing the ftruncate() method just makes it fall back to regular truncate. Other truncates could in theory be worked around by copying the file, but that has a lot of problems of it's own. Does this patch help in your case? Thanks, Miklos Index: sshfs.c =================================================================== RCS file: /cvsroot/fuse/sshfs/sshfs.c,v retrieving revision 1.55 diff -u -r1.55 sshfs.c --- sshfs.c 10 Jan 2006 10:54:38 -0000 1.55 +++ sshfs.c 23 Feb 2006 09:42:19 -0000 @@ -1900,7 +1900,6 @@ .statfs = sshfs_statfs, #if FUSE_VERSION >= 25 .create = sshfs_create, - .ftruncate = sshfs_ftruncate, .fgetattr = sshfs_fgetattr, #endif }, |
From: Joseph M L. <jo...@jo...> - 2006-02-23 13:28:41
|
Miklos Szeredi wrote: >> I just tried sshfs for the first time today, and after some debugging >> have found a problem likely related to an old version of openssh. >> >> The server is sshd version OpenSSH_2.5.2p2 running on Redhat 7.1 (not >> mine!). >> >> After some debugging, I see sshfs sending a truncate command and >> receiving a successful response. However, the file remains unchanged on >> the remote end. >> >> I realize it's unlikely, but is there anything I can hack in place to >> make this work with such an old version of openssh? > > Well, an ftruncate() to zero can be worked around with the following > patch. Plain truncate() already has a workaround for this, so > removing the ftruncate() method just makes it fall back to regular > truncate. > > Other truncates could in theory be worked around by copying the file, > but that has a lot of problems of it's own. Sorry, I failed to mention the non-zero truncate. I am using sshfs-1.5 with fuse 2.4.2 and already noticed the workaround for 0 sized truncates. This problem is definitely in sshfs_truncate (not ftruncate) and the size is non-zero. So, it appears the ssh server is silently ignoring the SSH_FXP_SETSTAT/SSH_FILEXFER_ATTR_SIZE request. Any other ideas? Thanks, Joe |
From: Miklos S. <mi...@sz...> - 2006-02-23 14:18:40
|
> Sorry, I failed to mention the non-zero truncate. I am using sshfs-1.5 > with fuse 2.4.2 and already noticed the workaround for 0 sized truncates. > > This problem is definitely in sshfs_truncate (not ftruncate) and the > size is non-zero. So, it appears the ssh server is silently ignoring > the SSH_FXP_SETSTAT/SSH_FILEXFER_ATTR_SIZE request. That's exactly what it does, this is why there's a workaround for the zero case, which is the most common. > Any other ideas? Well there are 4 cases: 1) newsize == 0 workaround exists 2) newsize < size copy + rename 3) newsize == size nop 4) newsize > size write zeroes to new end of file Case 2) is very messy: it can be grossly inefficient for large files, it's prone to races and only works if directory is writable. If these aren't problems for you, then implementing it should not be too hard. Woraround for 4) should be almost equivalent to real truncate (just a single block more disk usage), implementing it is simple. Miklos |
From: Miklos S. <mi...@sz...> - 2006-02-23 14:30:32
|
> Case 2) is very messy: it can be grossly inefficient for large files, > it's prone to races and only works if directory is writable. Oh, and any open files refering to this file will still refer to the old one. Or it could be done by reading the file up to the new size, storing it locally (in memory or in temporary file), then truncating to zero and writing contents back. It doesn't have the directory-writability and the open-file issues, so this seems like a better solution. Miklos |
From: Joseph M L. <jo...@jo...> - 2006-02-23 17:37:47
Attachments:
truncate-patch
|
This appears to work. Thanks for your help! Joe Miklos Szeredi wrote: >> Case 2) is very messy: it can be grossly inefficient for large files, >> it's prone to races and only works if directory is writable. > > Oh, and any open files refering to this file will still refer to the > old one. > > Or it could be done by reading the file up to the new size, storing it > locally (in memory or in temporary file), then truncating to zero and > writing contents back. It doesn't have the directory-writability and > the open-file issues, so this seems like a better solution. > > Miklos |
From: Miklos S. <mi...@sz...> - 2006-02-24 11:46:27
|
> This appears to work. Thanks. Applied with some cleanups and committed to CVS. A note on anon mmap: malloc/realloc use this internally for large allocations, so it's always better to just use malloc. Miklos |