GNOME Bugzilla – Bug 656225
Virtualbox on Windows host and Linux guest: inability to overwrite files in shared folders from gedit
Last modified: 2018-05-24 13:18:21 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
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".
Created attachment 291176 [details] Unmodified source for the current debian stable release
Created attachment 291177 [details] Modified source for the current debian stable release
Created attachment 291178 [details] Unmodified source for the current ubuntu release
Created attachment 291179 [details] Modified source for the current ubuntu release
Patrick can you maybe attach a patch so it is easier to review?
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?
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
Use the 'git format-patch' command (after creating commits in git). And you should work on upstream sources (with Jhbuild for example).
Created attachment 291292 [details] [review] patch for upstream sources (libglib-2.0.so.4300.0)
@patrick deneve Thanks for this patch. Worked for me on debian jessie.
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.
*** Bug 765208 has been marked as a duplicate of this bug. ***
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.
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 ;-(
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.
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"
Same for me with windows 10 host, and Ubuntu 16.04 guest, and gedit 3.18.3. Why is this bug still UNCONFIRMED?
(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.
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).
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.
-- 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.