VirtualBox

Ticket #9276 (reopened defect)

Opened 7 years ago

Last modified 2 weeks ago

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

Reported by: GameTheory Owned by:
Priority: major Component: shared folders
Version: VirtualBox 4.0.12 Keywords:
Cc: Guest type: Windows
Host type: Windows

Description

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.

Attachments

vboxsf.patch Download (1.3 KB) - added by muf 2 years ago.
shared folder: do not claim that the file was created if it existed already

Change History

comment:1 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by 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?

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by sunlover

Please try

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

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

comment:5 Changed 7 years ago by GameTheory

Works!

comment:6 Changed 7 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

The fix is included in VBox 4.1.2.

comment:7 Changed 7 years ago by marcoc

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:8 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by 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?

comment:10 Changed 7 years ago by 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?

comment:11 Changed 7 years ago by 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?

Changed 2 years ago by muf

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

comment:12 Changed 2 years ago by 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.

comment:13 Changed 6 months ago by 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:

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.

comment:14 Changed 6 months ago by 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 !

comment:15 Changed 6 months ago by 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.

Last edited 6 months ago by paulk (previous) (diff)

comment:16 Changed 2 weeks ago by 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 :)

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use