Ticket #9485 (closed defect: fixed)

Opened 8 years ago

Last modified 2 months ago

shared folders problem: IO to overwritten file (XP Home host) -> Fixed in 6.0.6

Reported by: krthie Owned by:
Component: guest additions Version: VirtualBox 4.1.2
Keywords: shared folder IO Cc:
Guest type: Linux Host type: Windows

Description (last modified by frank) (diff)

Hi I am using XP Home Edition (fully patched) as host, running Ubuntu 11.4 as guest (but similar problems with Ubuntu 10.4) on VBox 4.1.2.

I encounter problems in a rather specific set of circumstances when using shared folders (a discussion of this problem is on the forum

My program creates a new file, writes to the file, and then reads what it wrote itself. The read then fails if the file already exists (on a shared folder), but works fine if the file didn't exist.

For my latest tests, the shared folder is on d:\tmp (newly created) and permissions set to "Full Access" for everyone (set using Safe Mode). VBox runs as normal user "kris". I mounted the folder in Ubuntu as follows:

mkdir /home/kris/tmpmntD
sudo mount -t vboxsf -o uid=1000,gid=1000,rw dtmp /home/kris/tmpmntD

An example C program showing the problem:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
  char buffer[1024];
  int ret;

  /* Open file test.txt in current dir as "read-write new binary file" */
  FILE *fptr= fopen("test.txt","wb+");
  if (fptr==NULL)
      fprintf(stderr, "Error opening file\n");


  ret = fwrite(buffer, 1, 1024, fptr);
  printf("fwrite return (should be 1024): %d\n", ret);
  ret=fseek(fptr, 512, 0);
  printf("fseek return (should be 0): %d\n", ret);

  ret=fread(buffer, 1, 512, fptr);
  printf("fread return (should be 512): %d\n", ret);

  /* return from main checking if fread did read 512 bytes */
  return ret==512 ? 0 : 1;

When I run this program somewhere in a new directory on a shared-folder, the first time it works fine and reports:

write return (should be 1024): 1024
fseek return (should be 0): 0
fread return (should be 512): 512

This creates a file test.txt (of size 1024). Rerunning the program now fails as test.txt already exists:

fwrite return (should be 1024): 1024
fseek return (should be 0): 0
fread return (should be 512): 0

It works fine again once I remove test.txt, or of course if I run this program creating a file in a folder in the disk image. (It also fails if the existing file test.txt has zero size).

Note that the use of the "w+" flag for fopen is crucial for the bug to appear. If I use "r+", the program always succeeds.


VBox.log Download (45.6 KB) - added by krthie 8 years ago.

Change History

Changed 8 years ago by krthie


comment:1 Changed 7 years ago by hakan'

I'm facing the same problem now with VBox 4.2.4 on Ubuntu 12.04 host and guest. Is there anything I can provide to help get this resolved?

comment:2 Changed 7 years ago by hakan'

I think I may have found the root cause. If the file already exists it is opened by the function sf_reg_open. In this function, if flag O_TRUNC is set then SHFL_CF_ACCESS_WRITE will be set but never SHFL_CF_ACCESS_READ.

I tested by changing:

    if (!(params.CreateFlags & SHFL_CF_ACCESS_READWRITE))


    if (1)

I don't understand the intention of the test in the if clause above. Simply removing it like this seems to solve this particular problem.

Btw, I think I found another bug too, params.CreateFlags is never initialized in this function and the first assignment I can see is a |= .

comment:3 Changed 7 years ago by frank

  • Description modified (diff)

Thanks for the analysis, we have to check the code. Regarding params.CreateFlags not initialized: The complete params structure (including CreateFlags) is initialized by RT_ZERO(params);

comment:4 Changed 7 years ago by frank

And this problem does not seem to exist on Linux hosts.

comment:5 Changed 7 years ago by hakan'

I am running a Linux host, Ubuntu 12.04.

comment:6 Changed 7 years ago by hakan'

To clarify, I use Ubuntu 12.04 both for host and guest.

You're right about the initialization. I had missed the RT_ZERO(params) line.

comment:7 Changed 7 years ago by frank

That's interesting. Both, Guest Additions and VirtualBox on the host are 4.2.4?

comment:8 Changed 7 years ago by hakan'

Yes, Guest Additions on guest and VirtualBox on host are both 4.2.4.

comment:9 Changed 3 years ago by aeichner

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

Please reopen if still relevant with a recent VirtualBox release.

comment:10 Changed 3 years ago by bathomas

  • Status changed from closed to reopened
  • Resolution obsolete deleted


This problem still appears to persist. I was able to reproduce the same issue on a lubuntu 16.10 (64-bit) guest and Windows 10 Home host. VirtualBox was version 5.1.10 r112026 and VGA were installed. If it helps, the code was compiled with gcc 6.2.0-5ubuntu12.

I have tried mounting the shared folder both with and without auto-mount, with "Full Access". This did not make a difference. I wonder if this issue could be related to ticket #9276 and the recently proposed patch?

comment:11 Changed 2 months ago by bird

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Summary changed from shared folders problem: IO to overwritten file (XP Home host) to shared folders problem: IO to overwritten file (XP Home host) -> Fixed in 6.0.6

The test case works fine after the shared folder changes delivered in 6.0.6. Closing.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use