XP on Linux: VirtualBox shared folder not accessible by DarkPlaces engine, but works fine for Explorer

[divVerent]

As seen on the screenshot, the DarkPlaces game engine (used by Nexuiz, ​http://www.alientrap.org/nexuiz/) fails to open any files on my shared folder T: = \vboxsvr\temp, which is mapped to /tmp. However, Explorer and MS Office can work nicely with the shared folder.

I then tried to do the same, but with a locally installed Samba server - and that worked.

Maybe this is helpful - DarkPlaces is compiled using mingw32, and therefore uses msvcrt.dll and its open() function to access files, typically with the flags O_RDONLY | O_BINARY.

I am using VirtualBox 1.5.6-28266_Ubuntu_gutsy

On another note, I forgot to enter the email address when creating my account. Is there a way to enter it afterwards?

[divVerent]

screenshot of DP's error message

[divVerent]

Interestingly, the bug only appears if I undo the drive letter mapping first (and then occurs no matter if I remap the drive or if I use the UNC path).

[divVerent]

How to reproduce:

• Host system: Ubuntu gutsy; shared folder "temp" = /tmp, /tmp/mingw/bug1420.c is this .c file
• in /tmp/mingw, do: i586-mingw32msvc-gcc -s -o bug1420.exe -Wall -Wextra -Os bug1420.c (or use my provided exe file)

• Guest system: Windows XP Professional, all updates installed
• go to \vboxsvr\temp\mingw and copy bug1420.exe to the local drive for the following tests
• Clear all drive mappings for shared folders. Reboot for a clean start of this test.
• The order of the following tests does not matter, the result stays the same:
  • bug1420 \vboxsvr\temp\mingw\bug1420.c open: Invalid argument
  • type \vboxsvr\temp\mingw\bug1420.c no output
  • notepad \vboxsvr\temp\mingw\bug1420.c will work
• net use t: \vboxsvr\temp /persistent:yes
• repeat the tests, both using the UNC path or t:\mingw\bug1420.c: same result
• reboot (now Windows will assign drive T: from startup)
• repeat the tests, with same buggy output(?)
• open an explorer window with \vboxsvr\temp, enter the mingw directory in it and reboot
• IT WILL WORK:
  • bug1420 \vboxsvr\temp\mingw\bug1420.c (first line of C code)
  • type \vboxsvr\temp\mingw\bug1420.c (whole source)
  • notepad \vboxsvr\temp\mingw\bug1420.c will work

I have no idea what may be causing this weird behaviour. But it does NOT happen that way with a Samba share.

[divVerent]

test program for this bug

[pentagonik]

Hi divVerent,

I'll try to reproduce it.

[pentagonik]

I tested the 3D engine / dedicated server and your test program with our latest shared folders driver.

The bug1420.exe passes all your tests described above; it worked with and without mapping to a drive letter without problems.

The 3D engine and the dedicated server only ran on a mapped drive (e.g. T:), but not when using the direct UNC path like \vboxsrv\3d\nexuiz-dedicated.exe. Because Nexuiz is using the .pk3 format from ID software (simply a renamed ZIP file), it could be a zlib issue or something else we don't know.

In the soon future we'll release a new version of VirtualBox, containing the bugfixed shared folder driver.

[divVerent]

I forgot to update guest additions and therefore just did it - but as the new screenshot shows, this did not change anything.

Also, the bug1420.exe program seems to be not necessary, as cmd's built in "type" command already seems to show it. Let's see if I can get a clear cmd sequence to reproduce it assuming T: is a mapped drive and containing a file "existingfile.txt". Directly after booting, I opened up a cmd.exe and typed:

C:\Dokumente und Einstellungen\divVerent>t:

T:\>type existingfile.txt exists

T:\>c:

C:\Dokumente und Einstellungen\divVerent>type \vboxsvr\temp\existingfile.txt exists

C:\Dokumente und Einstellungen\divVerent>type \vboxsvr\temp\existingfile.txt

C:\Dokumente und Einstellungen\divVerent>t:

T:\>type existingfile.txt

T:\>

So it SUDDENLY started breaking for no reason... looking at the strace log, the data was never attempted to read in the failed attempts. What may be more interesting is that I never caught a close() for the file descriptor of existingfile.txt with strace.

[pentagonik]

I repeated all the new steps you added; these work fine (also with X retries) with the latest shared folders driver, which is not released yet. As I stated above, we gonna soon release a new version of VirtualBox, containing the bugfixed shared folder driver.

[pentagonik]

@divVerent: Did you try out the latest VirtualBox 1.6 as well as the latest guest additions? What are the results so far? Would be great to get some feedback from you!

[pentagonik]

Please make sure you got the latest shared folders files installed. To do this, take the following steps:

1. Go to the Windows-System32 directory (usually "C:\Windows\system32").
2. Locate the file "VBoxMRXNP.dll"
3. Check file properties (right click on file, choose "Properties"), lookup the item "File Version", post the version (1.x.x.xxxxx) here. Also, please provide the date/timestamp of the file!
4. Go to the "drivers" sub-directory (usually "C:\Windows\system32\drivers").
5. Redo step 3 with the file "VBoxSF.sys".