Empty files written over gvfs by some editors

This is happening with other editors as well. VI is immune going over SSH. Suspecting a bug in GVFS

This appears to be the same problem as with: https://bugs.launchpad.net/ubuntu/+source/geany/+bug/643253
Should they be merged?

Can someone comment on this? it is stopping me from using Maverick, so I'd call it a critical issue.

Reassigning to gvfs, since this appears to be gvfs-related. GnomeVFS is deprecated.

Can you try to reproduce this on gedit? It's very likely a duplicate of bug #606012.

Please check this bug https://bugzilla.gnome.org/show_bug.cgi?id=627567

There is a patch that fixes ssh and ftp mounts

sure, i see... but how to use it? :-/

i try a "sudo patch -p0 < file.patch" and i have some errors:ù

patching file b/client/gvfsfusedaemon.c
Hunk #1 FAILED at 948.
Hunk #2 FAILED at 968.
Hunk #3 FAILED at 1024.
Hunk #4 FAILED at 1406.
Hunk #5 FAILED at 1857.
Hunk #6 FAILED at 2336.
6 out of 6 hunks FAILED -- saving rejects to file b/client/gvfsfusedaemon.c.rej

i'm sure i'm missing somthing... but this bug is really dangerous for a web developer or a sys admin...

"sudo patch -p1 < patch_file" should do it: remember you can also "--dry-run", so that you won't trash anything at all and find out if the command would work or not.

Mmm... I am getting this:

s.rees@ws-17hm42s:~/Downloads$ sudo patch --dry-run -p1 < gvfs.patch
[sudo] password for s.rees:
patching file client/gvfsfusedaemon.c
Hunk #1 FAILED at 948.
Hunk #2 FAILED at 968.
Hunk #3 FAILED at 1024.
Hunk #4 FAILED at 1406.
Hunk #5 FAILED at 1857.
Hunk #6 FAILED at 2336.
6 out of 6 hunks FAILED -- saving rejects to file client/gvfsfusedaemon.c.rej

@stephen, you need to have the patch file inside the geany directory and run the command from there: you can see it's going to patch the client/gvfsfusedaemon.c file that is not there.

Are gedit also affected? When I use gedit instead of geany it seems to be working.

I consider this a critical bug. It directly affects my work.

No gedit and bluefish aren't affected and there is a workaround for geany and SciTE:
https://bugs.launchpad.net/ubuntu/+source/geany/+bug/643253

This is a critical bug because gvfs is no longer usable for anything other than browsing. I don't think we should work around it. This needs to be fixed as soon as possible before damage gets worse. There are more people out there who are not realizing this bug exists. I almost lost my months work over it... they might loose more or make security holes in their system.

you find the patched packages for 64bit on https://bugzilla.gnome.org/show_bug.cgi?id=627567#c16

or if you want to build gvfs yourself

sudo apt-get build-dep gvfs
mkdir tmpfuse
cd tmpfuse
apt-get source gvfs
cd gvfs-1.6.4
wget https://bugzilla.gnome.org/attachment.cgi?id=172274
patch -p0 < attachment.cgi\?id\=172274
dpkg-buildpackage -us -uc -b

@MeanEYE I agree with you, this is a very critical bug!
@Stephen Rees-Carter could please set the Importance to high?

I worked one day with the patch described in comment 14 and I didn't encounter any problem, but the FUSE issue persists: https://bugzilla.gnome.org/show_bug.cgi?id=627567#c9

@chicoff I've been trying ever since I started it, but I don't know how. There is no edit icon next to the Importance field...

This is obviously a critical bug, can someone with access please set the priority to high so it can get fixed? We shouldn't have to manually patch a bug which would be affecting a lot of people and causing a lot of damage to their work.

Affects "Freemind" too. Quite a dangerous bug. I'm just glad I had a backup and noticed straight away what was happening.

Marking Triaged/High. Upstream has proposed a fix.

The patch from upstream bug report fixes the bug, at least for nano.

A debdiff against 1.6.4-0ubuntu1 version

A debdiff for natty.

Go figure, natty version doesn't build due to changes in the toolchain. Fixing it now.

Attached is a natty version based on 1.6.4-0ubuntu1. Builds fine in local builder, patch for linking issue still has to be forwarded and I'm planning on doing it tomorrow.

i solved using this recompiled versions:
http://christiaan.baartse.nl/gvfs_1.6.4-0ubuntu1_amd64_fixed.tar.gz

very annoying bug! lost data, time, and nerves.
gvfs_1.6.4-0ubuntu2.debdiff works for me, thanks krzysztof klimonda!

SRU ack, please upload.

Hi!
I have a different problem with my recently updated Ubuntu 10.10 64Bit (intel).
If I open a file with geany on the network, make it shorter, and save it, the saved file is not actually shortned (keeps some of the text at the end). Gedit seems unaffected by the problem.
I also see that Geany is very slow in saving network files.

I wonder if this problem depends on the same cause.

Anyway the use_safe_file_saving=true config in Geany fixed both the problem and the slow saving thing (thx Yan)

@Maurizio Giunti
I think is the same problem, but the different behavior depend on the type of share (samba or ssh).
The patch of Tomas Bzatek also solves your problem.

Thx!

Wow, this is a CRITICAL dataloss bug. We have a patch. When is this gonna get into the repos?

Looks like there is a patch to gvfs upstream. Looks like it it is still a bit of a workaround? https://bugzilla.gnome.org/show_bug.cgi?id=627567#c9 Tomas seems to indicate this is originally a problem with fuse? Should we be worried about issues with other backends that use fuse?

@yareckon, the patch is the same and seems to work very good (tested daily with komodo edit, geany and meld)

On Mon, 2010-10-25 at 17:23 +0000, yareckon wrote:
> Looks like there is a patch to gvfs upstream. Looks like it it is still
> a bit of a workaround?
> https://bugzilla.gnome.org/show_bug.cgi?id=627567#c9 Tomas seems to
> indicate this is originally a problem with fuse? Should we be worried
> about issues with other backends that use fuse?

Yes, it's possible that the bug affects all fuse backends and not only
the gvfs one -- but there has been no answer from the fuse developers so
fa as far as I know. The bug is bad enough that I believe we shouldn't
wait until fuse developers speak up and fix it (or work around the
problem), at least for now, directly in the gvfs.

--
Sent from Ubuntu

I added my two bugs to the list of duplicates because I really hope they are.

I only experience the problems with kernel 2.6.33 and later with the 2.6.32 kernel everything works OK

See

Bug #666002

Bug #662361

Accepted gvfs into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I just did an upgrade to the version in maverick-proposed, rebooted, and still have the issue.

I'm running 10.10 x64

this bug in Ubuntu 10.10 affect Geany Editor

This bug was fixed in the package gvfs - 1.6.4-0ubuntu2

---------------
gvfs (1.6.4-0ubuntu2) natty; urgency=low

  * Apply patch from GNOME bug #627567 at
    http://bugzilla-attachments.gnome.org/attachment.cgi?id=172274
    to circumvent the possibility of data loss (LP: #658069).
 -- Daniel T Chen <email address hidden> Mon, 25 Oct 2010 19:30:18 -0400

@Stephen: Do you mean that, when you follow the test case I've written it fails or is the bug you have encountered still present? What can I do to reproduce it myself? I can see the patch is applied and it did fix the issue for some people according to the upstream bug report. I also couldn't reproduce the issue, that has been reported, myself after updating.

Mmm... I must have done something wrong before, because it appears to be working properly now.
I am using Zend Studio (Eclipse) to write to files in the .gvfs hidden directory.

Thanks so much to everyone involved in getting it fixed :)

I can confirm that after installing the new gvfs version, geany does correctly save files located on a ssh mounted filesystem

So this is fixed for me

Thank you

smb seems to be OK with the packages from ubuntu-proposed.

But ftp still has some problems.
Although geany and scite seem to work OK now I got issues withquite basic commands.

Testcase:

- connect a ftp share with nautilus.
- start a terminal and cd to the .gvfs/<my_ftp_share> directory
- then try the following

franco@TM6292:~/.gvfs/FTP als franco auf 192.168.0.13/franco/test$ ls
franco@TM6292:~/.gvfs/FTP als franco auf 192.168.0.13/franco/test$ for i in 01 02 03 04 05 06 07 08 09 10 ; do echo "$i Test line of text" >> sample.txt ; done
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
bash: echo: write error: Operation not supported
franco@TM6292:~/.gvfs/FTP als franco auf 192.168.0.13/franco/test$ cat sample.txt
01 Test line of text

On smb shares the above testcase work as intended. I have had no occasion to test WebDAV and ssh.

this bug in 10.10 affect MELD diff merge

Now I've installed maverick-proposed updates it seems to be fixed.

Unfortunately I've lost quite a lot of work due to this bug (and my over-reliance on Ubuntu/GVFS). Can this be resolved in maverick-updates ASAP?

This bug was fixed in the package gvfs - 1.6.4-0ubuntu1.1

---------------
gvfs (1.6.4-0ubuntu1.1) maverick-proposed; urgency=low

  * Apply patch from GNOME bug #627567 at
    http://bugzilla-attachments.gnome.org/attachment.cgi?id=172274
    to circumvent the possibility of data loss (LP: #658069).
 -- Daniel T Chen <email address hidden> Mon, 25 Oct 2010 19:30:18 -0400

I was happy to see that gvfs update today, and I thought it would have solved bug #655434 but it has not ....

https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/655434

fixed for me with the update.

confirming on my side that, it is re-working...
thanks for fix.

Still not working here, using gvfs-1.6.4-0ubuntu1.1 and Geany, saving via sftp

Saving a remote file in Geany gives in the debug log:

17:10:53: CRITICAL : handle_save_as: assertion `NZV(utf8_filename)' failed

Loading a remote file gives no error but retrieves no file either.