Content erased when editing and saving file on special unit such as mtp:// (Android device) and smb:// (Samba remote share)

[dariox86]

Easy steps to reproduce:

1. copy a non empty text file to a remote smb:// Samba share or mtp:// Android device;
2. open text file with L3afpad and check that it is not empty. Make a simple modification to the text file.
3. close L3afpad and save the file with the modification.
4. open the modified file again with L3afpad: the content is completely erased!

The same bug seems to affect GTK2+ version of Leafpad as well: http://unix.stackexchange.com/questions/202848/samba-erases-content-of-files-when-saving and https://bugs.archlinux.org/task/44681

Please note that smb shares are not the only units affected. MTP and other special mounts are affected, too.

[stevenhoneyman]

What is it that you're using that adds support for those "special units"?

Personally I use plain old /etc/fstab and nothing has ever been corrupted on samba shares, so that might narrow it down a little.

[dariox86]

Mounting it to a plain /etc/fstab probably it won't get corrupted, but what about hot mounted MTP devices such as an Android smartphone? Your configuration is a simple workaround, the bug is still there and I lost a couple of important files for it. By the way I am using LXDE on Parabola GNU/Linux that in turn uses gvfs-smb and gvfs-mtp to mount Samba shares and MTP devices respectively. They are mounted as special paths smb:// and mtp://.

[stevenhoneyman]

I wasn't suggesting it as a workaround, just wanted to find out where the problem is. It's likely gvfs related then - well that's a start!

[stevenhoneyman]

Might be other affected software too: http://forums.fedoraforum.org/showthread.php?t=249927

[stevenhoneyman]

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/658069

[dariox86]

From what you have found it looks like some applications are affected and some aren't. At the moment I'm trying to recover my files. If you don't mind, I will get back to make some tests when I'm done.

[dariox86]

I managed to recover my files. I was very upset about it. GVFS can't properly handle raw POSIX API calls, namely fwrite() used by L3afpad and the other affected applications. On the other hand, applications such as gedit that use the GIO library to save files are unaffected. I think GVFS "expects" GTK+ applications to use GIO instead of standard POSIX API. If you deem that your design using standard POSIX API calls to handle files is the right way to do operate and the problem solely lies in GVFS instead, feel free to close the bug report. Thank you very much for your attention and record-breaking prompt response.

[stevenhoneyman]

You're welcome; I'm glad you got your data back.

I'm happy to leave this open (although lets call it a 'compatibility enhancement request'!) - the rest of it uses GTK stuff so there's no reason why file handling can't be done "their way" too.

[Deevad]

Hi, I was affected by the same bug while using Leafpad to save a *.txt file from my laptop to my desktop over Samba ( while testing Lubuntu, it's the default editor). The txt file I lost is now 0 byte and empty. It's a shame because I spent 4 days to test and review more than 8 distributions and I was taking notes in this txt file... A lot of work lost. I'll try to see what I can do to recover.

[dariox86]

I understand the way you feel right now. You may try a full text search on the raw disk with wxHexEditor.

[brvcf]

I am just opening the Windows shared folder in (Lubuntu) PCManFM then opening, editing, and attempting to save the file same way as I would using the Windows 'network' icon.

[kuraga]

@stevenhoneyman good day! Consider this, please:

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 ?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680418#15

Whenever the buffer is saved to disk, call gtk_text_buffer_set_modified (@buffer, FALSE).

https://people.gnome.org/~shaunm/girdoc/C/Gtk.TextBuffer.set_modified.html

Reformulation of the bug: if some data written to a stream file pointer are still not flushed before opening+closing a second stream file pointer on that same file, the flushing of remaining data on the first file pointer will <...> fail when using gvfs+sftp (over a remote fs, or even over the local fs) with EOPNOTSUPP error code

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680418#34

And code:

	gtk_text_buffer_set_modified(buffer, FALSE);
	fclose(fp);

Also see https://bugzilla.redhat.com/show_bug.cgi?id=1295007#c1.

Thanks.