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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
