Bug#680418: gvfs-fuse: Wrongly sucessful posix fwrite call on a gvfs sftp mount can lead to data loss

[Nicolas Anonyme]

Hi Andreas!

Thank you for looking into this issue.

Reading your comments made me realise that I shouldn't have rushed my
first bug report and shouldnt have made unsupported assumptions making
me look like a fool. Now that you say it, it was obvious that it was
impossible for this strace to show the calls to the daemon (obvious
except after a long day of work and judgment clouded by my personnal
incompetence). Please disregard my previous 'analysis'.

Sticking to the facts : I did write this code sample mimicking the
leafpad behaviour, and succesfuly reproduced the data loss when using
it over a gvfs sftp mount. As my personnal analysis was erroneous, it
effectively does not imply gvfs is to blame. It only indicate a
correlations with this combination of factors not a causality (maybe
something like a specific race condition with the layers overhead ?).

As you said, It does not totally exclude a behaviour gvfs-fuse
different from the local filesystem :

You said also :
> Given that the strace is tracing the order of your writes against the gvfs
> fuse daemon, then I don't think it's much gvfs can do when the writes
> arrive in this order..

When I run my sample code without the gvfs-fuse, directly against
local filesytem, the writes are in the same order but the last write
succeed :
	strace -i -e trace=write,open,stat,read,close,signal ./write5kfile /tmp/5k.txt
	{
	 (...)
	 [    7eff782bb500] open("/tmp/5k.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
	 [    7eff782bb750] write(3, "********************************"...,
4096) = 4096
	 [    7eff782bb500] open("/tmp/5k.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = 4
	 [    7eff782bb690] close(4)             = 0
	 [    7eff782bb750] write(3, "********************************"...,
1024) = 1024
	 [    7eff782bb690] close(3)             = 0
	 (...)
	}

Whereas writing in the same file over gvfs-sftp leads to an unsupported result :
	strace -i -e trace=write,open,stat,read,close,signal ./write5kfile
~/.gvfs/${my_localhost_mounted_dir}/tmp/5k.txt
	{
	 (...)
	 [    7f9e9d478500]
open("~/.gvfs/${my_localhost_mounted_dir}/tmp/5k.txt",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
	 [    7f9e9d478750] write(3, "********************************"...,
4096) = 4096
	 [    7f9e9d478500]
open("~/.gvfs/${my_localhost_mounted_dir}/tmp/5k.txt",
O_WRONLY|O_CREAT|O_APPEND, 0666) = 4
	 [    7f9e9d478690] close(4)             = 0
	 [    7f9e9d478750] write(3, "********************************"...,
1024) = -1 EOPNOTSUPP (Operation not supported)
	 [    7f9e9d478690] close(3)             = 0
	 (...)
	}

But I don't know wich one is the expected correct result :\

Do you think I should also see with leafpad author(s) / package
maintenair(s) to fflush, fsync or close the file before calling
gtk_text_buffer_set_modified (which reopen the file in append mode) to
at least solve this behaviour in that application ?

Thank you again, Best regards

--
Nicolas