Writing large file fails on shared folder, succeeds on C:\

[Chas Emerick]

Stats:

• OS X 10.5.8 host, Macbook Pro hardware
• Windows Vista x64 guest
• vbox additions installed

Using the most recent release of the ​NSIS installer generator, writing an installer .exe that is going to be larger than some threshold (I believe the threshold is 16MB -- a guess arrived at by trial-and-error) succeeds when written to C:\, but fails when written to any shared folder location.

I'm attaching a *very* simple installer script, and a data file that will result in a total installer size > 16MB. The script takes a couple of arguments, making it easy to change where the generated installer is to be written and/or what file should be included in the installer (which should make debugging work somewhat easier).

Some sample output, showing a failure writing to G:\ (a shared folder in my environment), but success writing to C:\:

  G:\vbox-share-write-failure>makensis /Dinput=bigfile /Doutput=install.exe writeFailure.nsi
  Output: "G:\vbox-share-write-failure\install.exe"
  Install: 3 pages (192 bytes), 1 section (1048 bytes), 5 instructions (140 bytes)
  , 48 strings (826 bytes), 1 language table (230 bytes).

  Using zlib compression.

  EXE header size:               33792 / 35840 bytes
  Install code:                    836 / 2764 bytes
  Install data:               17457156 / 17457156 bytes
  Error: can't write 17457156 bytes to output
  Error - aborting creation process

  G:\vbox-share-write-failure>makensis /Dinput=bigfile /Doutput=C:\install.exe writeFailure.nsi
  Output: "C:\install.exe"
  Install: 3 pages (192 bytes), 1 section (1048 bytes), 5 instructions (140 bytes)
  , 48 strings (826 bytes), 1 language table (230 bytes).

  Using zlib compression.

  EXE header size:               33792 / 35840 bytes
  Install code:                    836 / 2764 bytes
  Install data:               17457156 / 17457156 bytes
  CRC (0x0202F8C2):                  4 / 4 bytes

  Total size:                 17491788 / 17495764 bytes (99.9%)

  G:\vbox-share-write-failure>

[Chas Emerick]

I was going to attach a data file that guaranteed failure, but it's too large for this trac install. You can generate your own data file that will cause the error pretty easily...just cat /dev/random > bigfile. (It needs to be random or otherwise irregular data because NSIS compresses files added to the generated installer.)

If you don't want to generate your own data file, you can download the one I was using ​here.

[Jon Schewe]

I've into this error as well. Would be nice if this could be fixed.

[Tijs van Roon]

EXACTLY The same problem here:

Program: makensis Host OS: Debian Linux Guest OS: Windows XP VirtualBox: 4.0

This used to work for years. Even with VirtualBox 3.x. The problem started after upgrading the guest-additions (I had an old early-3 version installed).

Copying the 22mb file makensis created on the C-drive to the H: drive by hand does seem to work. So the problem is not with the big size, but by the way makensis writes the file. And definitely in the guest-additions direction..

[Tien Nguyen]

Just ran into the same problem. Glad to find this post.

[Tijs van Roon]

Opened 2 years ago

Glad?

[Stefano]

• OS X 10.5.8 host, Macbook Pro hardware
• Windows Vista x64 guest
• vbox additions installed

I have same problem with:

• Debian Linux 2.6.39-bpo.2-686-pae host
• Windows XP Pro guest
• vbox additions installed

[VladV]

Most likely, the same problem here.
VirtualBox 4.1.8, Linux host (Ubuntu Natty, 2.6.38-13-generic-pae), Windows XP (32 bit) guest.

ReadFile call for a file in a shared folder fails, if nNumberOfBytesToRead is greater than 16M.
GetLastError gives error code ERROR_INVALID_PARAMETER 87 (0x57).
The same call succeeds if the file is on the VM's virtual disk, not in a shared folder.

Another person has mentioned the same problem here: ​http://stackoverflow.com/questions/3587117. This question also contains sample code to reproduce the error.

[Tijs van Roon]

Good link, shows the problem. It looks like read() won't allow the blocksize to be bigger as 16 Mb on a shared disk while real windows does. MakeNSIS probably reads/writes all data at once. So there is the debate of whether its virtualbox's error of implementing the limits different or if its makensis' not checking/using those limits properly.

But looking at the date of the ticket we can probably assume Oracle is not going to do anything about it. Not anyone from the dev team (is there any attached to this trac?) has responded. It is quite annoying though so maybe we'd have better luck asking nsis to workaround the problem.

[Michael Thayer]

Replying to knifter:

Good link, shows the problem. It looks like read() won't allow the blocksize to be bigger as 16 Mb on a shared disk while real windows does. MakeNSIS probably reads/writes all data at once. So there is the debate of whether its virtualbox's error of implementing the limits different or if its makensis' not checking/using those limits properly.

But looking at the date of the ticket we can probably assume Oracle is not going to do anything about it. Not anyone from the dev team (is there any attached to this trac?) has responded. It is quite annoying though so maybe we'd have better luck asking nsis to workaround the problem.

I will take the bate in your last sentence but one (before someone else writes an angry response), though I'm not the person to be fixing Windows guest shared folder issues. Please don't assume that no response from the developers means a lack of interest in bug reports. But if you look at the rate at which bugs are reported you will realise that there is no way our (quite small) team can deal with them all - even reading them all, which we do try to do, takes away a lot of development time. So there is sadly a certain randomness to which bugs get addressed, due to the fact that we want to fix as many as possible, but we can't even hope to address all of the interesting ones.

That said, when users actively investigate bugs as seems to be happening here it at least improves the chances we will try to fix them.

[Tijs van Roon]

Replying to michael:

... That said, when users actively investigate bugs as seems to be happening here it at least improves the chances we will try to fix them.

Hey, thnx for replying. Point taken and understood. I'm a developer myself, so I do know things can remain lying around for too long. I did not read any of the other (5000..) tickets so I have no idea about priorities over there. But I still (kindly) think 2 years is a long time for such an annoying bug while having seen major version releases in the meantime.

That being said, maybe someone has the time of finding the culprit in the OSE, as I suspect that the same issue will pop up there.

[Anton Pomozov]

Same here. Fix the bug, guys!!!

[sunlover]

The bug should be fixed in the new 4.2 additions: ​http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.2.7-83629.iso

Please test it. Thanks.

[sunlover]

Fixed in VBox 4.2.8.