After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 608910 - gvfsd-sftp: unable to append to file via fuse-daemon
gvfsd-sftp: unable to append to file via fuse-daemon
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: sftp backend
1.4.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2010-02-03 18:28 UTC by potter000
Modified: 2013-10-25 04:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sftp: Allow seeking when opening for append (1.15 KB, patch)
2013-10-05 21:16 UTC, Ross Lagerwall
accepted-commit_now Details | Review

Description potter000 2010-02-03 18:28:50 UTC
Hello, 

I have faced some strange behaviour when mounting a GVFS-SFTP share.
This bug is similar to https://bugzilla.gnome.org/show_bug.cgi?id=608908, though the backend is different. The configuration is the same (Ubuntu 9.10 Karmic with Gnome 2.28.1 and GVFS 1.4.2)

Steps to reproduce behaviour:
1. Mount a GVFS-SFTP share (via sftp://someserver/someshare)
2. Open terminal and cd to this share
3. Run commands:
user@host:~/.gvfs/sftp on someserver$ echo 100 > ./test
user@host:~/.gvfs/sftp on someserver$ echo 200 >> ./test
4. Expected result:
"200" appended to file contents
5. Real result - an error:
bash: echo: write error: Operation not supported

When using a text editor writing with fopen (e.g. Geany:
http://www.geany.org), this behaviour leads to loss of all file contents (e.g. after I save a file, it has a 0-byte size and is empty). When using gedit (which seems to write via g_file_set_contents), all is OK.

Again, this was not present in Ubuntu Jaunty (Gnome 2.26, GVFS 1.2.2).

Please let me know if that is a bug or a normal behaviour.
Comment 1 Ulrich Keller 2011-08-31 19:46:25 UTC
The issue is still present in GVFS 1.8.2 (Arch Linux 32bit, Kernel 3.0.3, Gnome 3.0.2).
Comment 2 Tomas Bzatek 2011-09-01 12:52:31 UTC
(In reply to comment #1)
> The issue is still present in GVFS 1.8.2 (Arch Linux 32bit, Kernel 3.0.3, Gnome
> 3.0.2).

You mean the 0-byte sized file or the append error?
Comment 3 Ulrich Keller 2011-09-01 14:26:38 UTC
I mean the append error. I was under the impression that the 0-byte error is a consequence of the append error under some circumstances. Sorry for not being more specific.
Comment 4 ville.ranki 2012-02-06 15:34:39 UTC
Append error still exists here in gvfs 1.10.0 (Ubuntu Oneiric). Also I got 
"Operation not supported" by moving a file from local fs to remote.
Comment 5 ville.ranki 2012-03-30 13:01:41 UTC
Could someone from BugSquad please mark this as confirmed and update version to 1.10.x? 

This should be a high priority bug as it prevents normal usage of sftp backend and may cause data loss.
Comment 6 Ross Lagerwall 2013-10-05 21:16:48 UTC
Created attachment 256550 [details] [review]
sftp: Allow seeking when opening for append

Although it has no effect, allow seeking when opening a file for append
to allow programs to write to files opened for append through the fuse
backend without failing with ENOTSUPP.
This is similar to POSIX behavior which allows seeking on a file opened
with O_APPEND.
Comment 7 Ross Lagerwall 2013-10-05 21:20:09 UTC
The problem is two-fold:
Firstly, OpenSSH does not honor the append flag for sftp.  I have sent a patch upstream for this:
http://marc.info/?l=openssh-unix-dev&m=138053388830753&w=2
This makes appending work with GIO.

Secondly, the patch marks the file as seekable which allows appending to work with the fuse daemon instead of failing with "operation not supported".
Comment 8 Ross Lagerwall 2013-10-15 05:25:52 UTC
The patch has been applied to OpenSSH upstream [1].  This means that g_file_append_to() now works correctly.  With the minor patch in #6, append also works for the fuse daemon.

[1] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sftp-server.c.diff?r1=1.100;r2=1.101
Comment 9 Ondrej Holy 2013-10-17 12:31:38 UTC
Review of attachment 256550 [details] [review]:

It looks good.
Comment 10 Ross Lagerwall 2013-10-25 04:20:16 UTC
Pushed to master as 629c5cc.