Text truncated when I save a txt file during a sftp session over nautilus

[Sergio Rus]

Binary package hint: leafpad

When I save a txt file during a sftp session over nautilus, there is a piece of text that is always truncated. It seems like it happens only with this txt file (see the attached file). If I repeat the same process over a ssh -X session (in a terminal), everything is ok: the saved file is correct.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Petr Flídr (petrf)]

This problem happens when file is XML opened over PCManFM too.

[Nicolas (pathogenyx)]

Same bug under debian with leafpad 0.8.18.1-3 : in a sftp directory mounted with nautilus, after editing and saving a text file with leafpad, my text file get truncated (at exactly 4096 bytes ...). There's no problem when editing/saving it with gedit though.

[Nicolas (pathogenyx)]

After a few tries, I think I can say the bug is not related to leafpad per se, but to gvfs and fuse :

I checked the length returned by the "fwrite()" in the save function of leafpad (file_save_real in file.c) and it returns a value > 4096 bytes. But the file on the gvfs is only 4096 byte long.

Searching for "gvfs truncate" issues returns lot of results : seems gvfs is not fully compatible with POSIX api (like the basic and standard fwrite function used by leafpad or emacs) but should be used with gio api (probably used by gedit).

There's probably already a bug filled for this, so hopefully a futur release of gvfs will fix this.

[quadra (info06)]

It may be also a gvfs issue, but this affects data integrity and therefore it's a hot one. It's easy to loose files with this.
I think "importance" of this bug should be set to "high".

There must be a way to fix it in leafpad, not gvfs, as it doesn't appear when editing the same text files in gedit, nor in abiword.

[surendra beniwal (sbnwl)]

I confirm this bug is still present till today [May, 2016].

I edited a *.txt file in leafpad over sftp in nautilus. After I saved the file in leafpad and exited, the file size became 0 bytes. It erased entire file contents upon saving! I am very disappointed, since I do not have the backup of the file.

I also think 'importance' of this bug should be set to "HIGH".

Ubuntu 15.10
Leafpad 0.8.18.1

[hippieshaker (bladeboy2000au)]

I'm not sure if it's the same issue as originally reported, but I confirm the behaviour Surendra has reported. It happens on SFTP/SSH connections as well as SMB, and seems to only occur on text files less than 4096 bytes. Yes this is a dangerous bug - I was just lucky to notice before losing important notes.

If you reverse lines 232 & 233 in src/file.c so that it becomes:
  fclose(fp);
  gtk_text_buffer_set_modified(buffer, FALSE);

and recompile it seems to fix the bug - the files save correctly. There must be some issue between GVFS and gtk_text_buffer_set_modified where the buffer is lost.

[EB (ebreport)]

I have the same problem, so I confirm it is still a bug [October, 2016]. Indeed a dangerous bug. Lucky I found old files in my backup.

[schamane (schamane)]

For reference, I think, the following reports highlight the root cause(s):

#680418 - gvfs-fuse: Wrongly sucessful posix fwrite call on a gvfs sftp mount can lead to data loss
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680418

1295007 – Non-GIO (POSIX) API call to save data truncates file to 0 bytes
https://bugzilla.redhat.com/show_bug.cgi?id=1295007

However, it seems that Leafpad is one of only a few applications where the bug triggers. Off the top of my head I only know Leafpad and L3afpad.

[Shay Walters (shayw)]

For what this is worth... I'm running a fully-updated Lubuntu system (18.04.3 LTS) and I'm still seeing this problem with leafpad and smb shares. Leafpad shows version "Leafpad 0.8.18.1" on the help/about screen. It appears that there was a fix released in Debian 6 months ago, but either it didn't make it down to the lubuntu repositories, or it didn't get fixed.

[Chris Guiver (guiverc)]

Thank you for reporting this bug to Ubuntu.

Ubuntu 20.10 (groovy) reached end-of-life on July 22, 2021.
Ubuntu 19.10 (eoan) reached end-of-life on July 17, 2020.
Ubuntu 19.04 (disco) reached end-of-life on January 23, 2020.
Ubuntu 18.10 (cosmic) reached end-of-life on July 18, 2019.
Ubuntu 17.10 (artful) reached end-of-life on July 19, 2018.
Ubuntu 17.04 (zesty) reached end-of-life on January 13, 2018.
Ubuntu 16.10 (yakkety) reached end-of-life on July 20, 2017.
Ubuntu 16.04 (xenial) reached end-of-life on April 29, 2021.
Ubuntu 15.10 (wily) reached end-of-life on July 28, 2016.
Ubuntu 15.04 (vivid) reached end-of-life on February 4, 2016.
Ubuntu 14.10 (utopic) reached end-of-life on July 23, 2015.
Ubuntu 14.04 (trusty) reached end-of-life on April 25, 2019.
Ubuntu 13.10 (saucy) reached end-of-life on July 17, 2014.
Ubuntu 13.04 (raring) reached end-of-life on January 27, 2014.
Ubuntu 12.10 (quantal) reached end-of-life on May 16, 2014.
Ubuntu 12.04 (precise) reached end-of-life on April 28, 2017.
Ubuntu 11.10 (oneiric) reached end-of-life on May 9, 2013.
Ubuntu 11.04 (natty) reached end-of-life on October 28, 2012.
Ubuntu 10.10 (maverick) reached end-of-life on April 10, 2012.
Ubuntu 10.04 (lucid) reached end-of-life on May 9, 2013.
Ubuntu 9.10 (karmic) reached end-of-life on April 30, 2011.
Ubuntu 9.04 (jaunty) reached end-of-life on October 23, 2010.
Ubuntu 8.10 (intrepid) reached end-of-life on April 30, 2010.
Ubuntu 8.04 (hardy) reached end-of-life on May 12, 2011.
Ubuntu 7.10 (gutsy) reached end-of-life on April 18th, 2009.
Ubuntu 7.04 (feisty) reached end-of-life on October 19, 2008.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in.