In attachment a tentative of patch (but as it's already 2 am, I don't
guarantee anything).
--- leafpad-0.8.18.1_orig/src/file.c 2010-12-23 14:54:16.0 +0100
+++ leafpad-0.8.18.1/src/file.c 2016-11-23 00:45:53.0 +0100
@@ -180,6 +180,7 @@
gint file_save_real(GtkWidget *view, FileInfo
Package: leafpad
Version: 0.8.18.1-5
X-Debbugs-CC: bladeboy200...@gmail.com
Severity: critical
Some mishandling of error return code in the saving function of
leafpad can lead to data loss.
When a file ($FILE) is saved in leafpad, it calls the functions
file_save_real(file.c:180):
- The
I rewrote a custom demo soft for this (see attachments).
# When trying to write data into a file on local filesystem
# All data are writen onto the disk
./write_into /tmp/file.txt 3
[fnFileSave] Will try to write 3 byte(s) into [/tmp/file.txt]
[fnFileSave] Opening first stream pointer on file
Hello,
I once again lost a (precious) file to this bug (using leafpad with gvfs
over sftp) .
( gvfs 1.28.2 , leafpad 0.8.17 , debian 8 or ubuntu xenial )
Leafpad is just the trigger here. as the behavior of gvfs+sftp differs from
the local ext4 file system, it could cause some data loss in
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
Package: gvfs-fuse
Version: 1.12.3-1+b1
Severity: critical
Tags: upstream
Justification: causes serious data loss
Dear Maintainer,
* What led up to the situation?
After some of my files got truncated at 4096 bytes when saved in leafpad
over agvfs sftp mount, I did some debug, and found that
6 matches
Mail list logo
