VirtualBox

Ticket #5830 (closed defect: fixed)

Opened 4 years ago

Last modified 14 months ago

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

Reported by: cemerick Owned by:
Priority: major Component: shared folders
Version: VirtualBox 3.1.2 Keywords:
Cc: Guest type: Windows
Host type: Mac OS X

Description (last modified by sunlover) (diff)

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>

Attachments

writeFailure.nsi Download (503 bytes) - added by cemerick 4 years ago.

Change History

Changed 4 years ago by cemerick

comment:1 Changed 4 years ago by cemerick

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.

comment:2 Changed 3 years ago by jpschewe

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

comment:3 Changed 3 years ago by knifter

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..

comment:4 Changed 3 years ago by tienhn

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

comment:5 Changed 3 years ago by knifter

Opened 2 years ago

Glad?

comment:6 in reply to: ↑ description Changed 2 years ago by stefano-k

  • 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

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

comment:8 follow-up: ↓ 9 Changed 2 years ago by 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.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 2 years ago by michael

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.

comment:10 in reply to: ↑ 9 Changed 2 years ago by knifter

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.

comment:11 Changed 18 months ago by zhivotnoe

Same here. Fix the bug, guys!!!

comment:12 Changed 14 months ago by sunlover

  • Description modified (diff)

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.

comment:13 Changed 14 months ago by sunlover

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

Fixed in VBox 4.2.8.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use