After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656225 - Virtualbox on Windows host and Linux guest: inability to overwrite files in shared folders from gedit
Virtualbox on Windows host and Linux guest: inability to overwrite files in s...
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 765208 (view as bug list)
Depends on:
Blocks: 760868
 
 
Reported: 2011-08-09 15:16 UTC by Rocio Dominguez-Vidana
Modified: 2018-05-24 13:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Unmodified source for the current debian stable release (30.68 KB, application/octet-stream)
2014-11-21 14:26 UTC, Patrick Deneve
  Details
Modified source for the current debian stable release (30.71 KB, application/octet-stream)
2014-11-21 14:26 UTC, Patrick Deneve
  Details
Unmodified source for the current ubuntu release (30.06 KB, application/octet-stream)
2014-11-21 14:27 UTC, Patrick Deneve
  Details
Modified source for the current ubuntu release (30.00 KB, application/octet-stream)
2014-11-21 14:28 UTC, Patrick Deneve
  Details
patch for upstream sources (libglib-2.0.so.4300.0) (5.43 KB, patch)
2014-11-23 04:43 UTC, Patrick Deneve
needs-work Details | Review

Description Rocio Dominguez-Vidana 2011-08-09 15:16:32 UTC
When you are using Virtualbox with a Windows host and an Ubuntu guest, you can't modify files from Linux, it sends you this error:

** (gedit:2107): WARNING **: Hit unhandled case 0 (Error renaming temporary file: Text file busy) in parse_error.

And it generates a file .goutputstream-XXXXXX

It has been reported both in Virtualbox and in Ubuntu, but no solution has been proposed there, and they have mentioned that it might be something with gedit and other applications (such as Nautilus).

Here are the references:

http://www.virtualbox.org/ticket/9203

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594162

https://bugs.launchpad.net/ubuntu/+bug/323091
Comment 1 Tim Sheerman-Chase 2014-06-19 19:18:53 UTC
As far as I can tell, the problem is in the way glib saves a file by writing to a temporary file and renaming to the final name. This is don't without closing the file, which is ok on most linux file systems but not on windows.

I'll take a more serious look later but I'd start with gio/glocalfileoutputstream.c and particularly the function _g_local_file_output_stream_really_close which contains the error string "Error renaming temporary file".
Comment 2 Patrick Deneve 2014-11-21 14:26:21 UTC
Created attachment 291176 [details]
Unmodified source for the current debian stable release
Comment 3 Patrick Deneve 2014-11-21 14:26:53 UTC
Created attachment 291177 [details]
Modified source for the current debian stable release
Comment 4 Patrick Deneve 2014-11-21 14:27:54 UTC
Created attachment 291178 [details]
Unmodified source for the current ubuntu release
Comment 5 Patrick Deneve 2014-11-21 14:28:38 UTC
Created attachment 291179 [details]
Modified source for the current ubuntu release
Comment 6 Ignacio Casal Quinteiro (nacho) 2014-11-21 14:31:41 UTC
Patrick can you maybe attach a patch so it is easier to review?
Comment 7 Patrick Deneve 2014-11-21 14:43:46 UTC
A month or two ago I started testing some linux distributions in virtualbox on a windows host, but linux suffered from several problems (gedit, nautilus).  I tried replacing gedit by another editor. But several other editors are having the same problem when trying to save a file in a virtualbox shared folder on a windows host.  A almost gave up on linux.

BUT I gave it another try.
After being pointed in the right direction by the comments found on the internet I modified the source for "glocalfileoutputstream.c" and tested it on the debian stable release (glib version 2.30).  Gedit and nautilus now function as they should.
I also adapted the source version 2.40 (=2.42)(for ubuntu and lfs) but haven't tested it yet.
When I studied the source I had the impression it wasn't patched from the redhat source.  So it's possible redhat has the same problem?

Could someone checkout this proposal and inject it in the affected linux distributions?
Comment 8 Patrick Deneve 2014-11-21 14:49:19 UTC

Ignacio,
It's my first compilation on linux.  How can I create a patch?
I already created a deb package.  I have also extracted the source of libgio.so.0.3200.4 from it.
Patrick
Comment 9 Sébastien Wilmet 2014-11-21 14:58:14 UTC
Use the 'git format-patch' command (after creating commits in git). And you should work on upstream sources (with Jhbuild for example).
Comment 10 Patrick Deneve 2014-11-23 04:43:16 UTC
Created attachment 291292 [details] [review]
patch for upstream sources (libglib-2.0.so.4300.0)
Comment 11 Jan 2015-05-10 17:59:39 UTC
@patrick deneve
Thanks for this patch. Worked for me on debian jessie.
Comment 12 JP Vossen 2016-01-16 05:17:07 UTC
My use case is a Mint 17.x VM using a VirtualBox vboxsf to a Win8.1 host.  I had this same problem in Geany and it was driving me insane until I found http://wiki.geany.org/config/all_you_never_wanted_to_know_about_file_saving and then "Edit > Prefs > Various > use_atomic_file_saving: checked" fixed it for me.  Be sure to read the URL as there are implications.  Obviously this does not fix Gedit but it may be an acceptable work-around for some people.
Comment 13 Ondrej Holy 2016-06-10 06:24:39 UTC
*** Bug 765208 has been marked as a duplicate of this bug. ***
Comment 14 Markus Grob 2016-06-10 10:56:39 UTC
I have the same behaviour with Suse Leap in a Windows 7 machine. First all worked well, but it seems, in December or January the behaviour changed to the situation described above. Now I have to safe every file twice and take a look if it was really written or not.
I use Bluefish as editor and I'm not sure, where I should change to the atomic saving.

Hope you could help me.
Comment 15 Markus Grob 2016-06-10 11:05:45 UTC
I have found a solution for Bluefish and it's something like for Gedit. I have disabled to make a security copy of the file while saving. With this, the original file will not be deleted anymore.
The security solution makes the program unsecure ;-(
Comment 16 Markus Grob 2016-06-10 11:27:09 UTC
The solution was no solution. Without this entry, Bluefish doesn't save something. The save button turns to "saved" but nothing happens on the file.
Comment 17 bupthebroker 2017-03-09 08:21:22 UTC
Issue still exists:
Windows 7 host
Guest: Linux 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013 i686 i686 i686 GNU/Linux

"Unexpected error: Error renaming temporary file: Text file busy"
Comment 18 Andrea Vai 2017-10-09 15:48:11 UTC
Same for me with windows 10 host, and Ubuntu 16.04 guest, and gedit 3.18.3.
Why is this bug still UNCONFIRMED?
Comment 19 Emmanuele Bassi (:ebassi) 2017-10-09 15:54:15 UTC
(In reply to Andrea Vai from comment #18)
> Same for me with windows 10 host, and Ubuntu 16.04 guest, and gedit 3.18.3.
> Why is this bug still UNCONFIRMED?

Because there's no special meaning endowed to the 'unconfirmed' state.
Comment 20 DavidR 2018-01-20 17:58:58 UTC
This bug does still exist. I checked the latest source for libglib2.0-0 and the patch posted here has not been implemented upstream, despite being proposed 3 years ago. This bug affects more than just gedit, since a variety of other software uses the same libraries from glib. I just applied this patch on my system, Linux Mint 18.3 running in Virtualbox on a Windows 10 host, and it still corrects the bug 3 years later. Is there a reason why this patch has not been implemented upstream, for example, does it produce unwanted behavior somewhere else? Or is it just... no one around to do it (which is understandable).
Comment 21 Philip Withnall 2018-01-22 11:16:55 UTC
Review of attachment 291292 [details] [review]:

I’d rather not lose the behaviour on Linux of renaming while the file is open. That means we keep a handle to the file at all times, and avoid race conditions (TOCTTOU).

It looks to me like it would be simpler to just check for EBUSY being returned from the g_rename() call. If so, close the file and try the rename again. If the rename fails a second time, return that error.
Comment 22 GNOME Infrastructure Team 2018-05-24 13:18:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/438.