If editing a file in a shared folder (folder on the host) from the guest, file is not terminated properly and corrupted. => fixed in 6.0.6

[GameTheory]

Using Windows guest and on Windows host. If I open a shared folder (file resides on host, and is a shared folder on guest) and edit a text file (on the guest), if I shorten the file and re-save, the file is not terminated at the new shorter length.

In other words, I open up a shared folder (folder from host) text file from the guest in a text editor. Let's say the file looks like this:

111111 222222 333333 444444 555555 666666 777777 888888

Now I remove some stuff to make it smaller:

111111 222222 333333 theend

and re-save the file (overwrite original).

Now I close the file and re-open it (either in guest or host). It will read something like

111111 222222 333333 theend 555555 666666 777777 888888

It has not terminated the file at the shortened length and now I've got a corrupted file. If I do this with a networked folder rather than a shared folder, it works fine. (Even with same folder/file.)

I notice you just updated to 4.1 and I am still using 4.0.12, but I can tell you this is a long-standing bug and has been that way for several versions at least (or forever as far as I know). I have not tested this on Linux guests or hosts.

[sunlover]

What exact versions of Windows host and guest do you use? Which "text editor" version? Also please attach VBox.log file of the VM.

[GameTheory]

Windows Host: Win7Pro 64-bit Windows Guest: XPPro

Text editor: TextPad. I've just tested with with MS NotePad and also EditPadLite and they seem to be ok. So the bug is actually in TextPad? But what would cause it to work most of the time but not with a shared folder?

[sunlover]

Thanks for the information. This means that TextPad uses some function, which does not work correctly on a shared folder. We will try to reproduce this here.

[sunlover]

Please try

 http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r73157.iso

The problem is fixed there. TextPad works now in XP Pro guest.

[GameTheory]

Works!

[frank]

The fix is included in VBox 4.1.2.

[marcoc]

Sorry, not fixed for me. Exactly the same problem happens with VBox 4.1.4 Linux host x64, Windows 2000 guest with Windows Additions 4.1.4 using Notepad++ to edit files on a shared folder, whenever text file length is reduced. This does not happen with Notepad instead.

[sunlover]

Thanks for the report. Not reproducible in a Windows XP guest. May be this only happens with Windows 2000. We will look at this issue. However this has a low priority.

[marcoc]

I tried in a Windows XP guest on the same Linux host: identical behavior. Create or copy a text file on a shared folder, add text, save, delete text at end, save again, reload from disk and you will see again the text you just deleted.
I suspected it could hardly depend on guest OS version, it should rather be an issue between guest additions and host-dependent storage emulation. Could it have been fixed with Windows hosts only?

[michael]

Not reproducible here either on a 64bit Ubuntu Linux host (VBox trunk, not 4.1, but with current 4.1 Additions), following the instructions in the original bug description using Notepad++ on a Windows XP guest.

Are you sure that you updated the Additions correctly in the guest?

[marcoc]

Yes, I did it just before testing, as I realized they were outdated. Tooltip shows "Guest Additions 4.1.4r74291".

Is there any further testing I can do to get more info for you?

[muf]

shared folder: do not claim that the file was created if it existed already

[muf]

I ran into this issue too; Linux host, windows 7 guest. VBox host version: 5.1.6_Debian r110634, guest additions version 5.1.8 r111374.

When editing a file on a shared folder using vi (cygwin) within the guest, and the saved size is shorter than the original size, the file will not get truncated to the new size. This is not a problem if done on a file on a local filesystem.

Using procmon, I found the source of the problem: On local filesystem, the CreateFile operation returns OpenResult = Opened. The program then truncates the file to size 0 and writes the new content.

On shared folder, the CreateFile operation returns OpenResult = Created. In this case, the program does NOT truncate the file (it shouldn't be necessary if the file really was newly created), but just writes the new (shorter) content, leaving the remaining old content alone - hence, the file is now corrupted.

The attached patch fixes the issue.

[vaab]

Same issue; Linux host (ubuntu 16.04) windows 7 guest, VBox & Guest additions 5.2.10 r122088 .

Seems to be a long lasting bug in the implementation of shared folders:

• https://www.virtualbox.org/ticket/4771
• https://www.virtualbox.org/ticket/2257

Very easy to reproduce with bash (version 4.4.12(3)-release (x86_64-unknown-cygwin)), on a shared folder do:

$ echo abc > test.txt

$ cat test.txt
abc

$ echo x > test.txt

$ cat test.txt
x
c

Doesn't occur on direct folders (non-shared folder). Will try the fix from @muf.

[vaab]

Confirming that @muf's patch was successfully applied to ubuntu 16.04 source package (which is version 5.1.34_Ubuntu r121010, fetched through apt-get source virtualbox), and fixed the given test.

Many thanks @muf !

[paulk]

In order to prioritize this patch for integration, we need a sufficiently detailed explanation about why this is the right thing to do, and that, as a host-side change, some assurance that it won't break other guest OSes.

[muf]

@vaab: thanks for the report, I'm glad it helped :)

@paulk: OK, I will try to explain more detailed why current behavior is broken, and how the patch fixes it.

If a file on a shared folder is opened with O_CREAT (which turns into SHFL_CF_ACT_CREATE_IF_NEW in vbsf), ie., create the file if it doesn't already exist, vbsfOpenFile will always return SHFL_FILE_CREATED *even if the file actually already did exist*.

In other words, the application is (incorrectly) told that the file is newly created; some applications (at least cygwin based ones, but maybe others too) take this as a hint that it is not necessary to truncate the file before writing new content and closing the file. If the old file size was greater than what was written this time around, excess content is left in the file.

The patch fixes this by only returning SHFL_FILE_CREATED in case the file did not already exist or if it was empty (it would require additional code and execution time to distinguish between these two cases with no benefit).

Regarding breaking other guest OSes or not: I'm not sure if other OSes than Windows will reflect the SHFL_FILE_CREATED flag back to the application, but I think that it is obvious that if they do, the new behavior is more correct for them too - and if they don't, well, they don't care :)

[vaab]

Still not fixed in 5.1.38_Ubuntu r122592 ...

Here's a full run down of the patching process on ubuntu 16.04 (should be not so different on more recent releases):

  cd /tmp
  sudo apt-get source virtualbox &&
  sudo apt-get build-dep virtualbox &&
  cd virtualbox-* &&
  sudo apt-get install curl &&
  curl 'https://www.virtualbox.org/attachment/ticket/9276/vboxsf.patch?format=raw' | patch -p0 &&
  dpkg-buildpackage -rfakeroot -b && 
  cd .. &&
  sudo dpkg -i virtualbox_*.deb

No need to relaunch virtualbox. The compilation can take long.

[socratis]

Replying to vaab:

Still not fixed in 5.1.38_Ubuntu r122592 ...

It looks like you're using Ubuntu's fork version of VirtualBox. You can either ask in their forums for help, or completely remove/uninstall/delete/purge their version and install the official version from the Linux Downloads section of VirtualBox.

[vaab]

@socratis I can confirm this bug on 6.0.4 r128413 (Qt5.6.1), running on ubuntu 16.04.

Is there any way to have deb-src enabled on the official apt repository so as to be able to use standard apt-get source procedure to get the patch in ?

Why not include the current patch in VirtualBox ?

[bird]

I hope we've fixed this in 6.0.6 / svn. Haven't had time to test it yet though.

[michael]

Re-opening, as there is currently no 6.0.6 release. I will close it once the fix is in a released version.