virtualbox.org

Virtualbox version 3.2.6 PUEL,
- Host: Windows Vista SP3, completely up-to-date
- Guest: Ubuntu 8.04.4, completely up-to-date (based on Turnkeylinux.org's LAMP 2009.02-hardy release)

Files are hosted on the Windows side for performance and availability reasons, and shared with Ubuntu using a shared folder. fstab entry:

www   /mnt/www   vboxsf   rw,auto   0   0

Ubuntu then serves the files back to me using Apache2 over a host-only network connection. On the Windows side I'm using both Google Chrome (most recent dev version) and Mozilla Firefox 3.6 (also up-to-date).

The files were pulled off a Unix-type ftp server using Filezilla, which automatically converted line endings for text mode files to DOS format (which is correct). On the Ubuntu side, nano shows that the files are DOS format.


The problem: after editing a pure text file (e.g. a CSS file), changes are not visible or are shown incorrect on the Windows side, except after a VM reboot or a remount of the affected share.

For instance, I have a file called test.css which has a few kb of text data. On first request (before editing), the file is shown correctly in the browser. Reported file size in the HTTP headers is equal to the file size on both Windows and Ubuntu sides. Then I add some lines or characters anywhere in the file. I refresh (or completely restart) my browser, but it still shows the old data, with some apparently unreadable characters (they look like <?> in Firefox but are not shown in Chrome) appended at the end (!). When characters are only edited and the file size hasn't changed, no changes are visible whatsoever.

Converting line endings to Unix format (or Mac format) using nano results in the file being truncated in the output. The file size still shows the correct value, but the line endings apparently weren't converted. This is confirmed after copy-pasting the browser contents into Notepad++, which does show the right character count, but the wrong line ending (still DOS format).

Clearly there is an issue here, but what?

I've tried:
- Unmounting and remounting the share. Files are served correctly again, until new changes are applied. This made me think the issue might be VBox related.
- Only unprocessed text files seem to have this issue (e.g., CSS files). PHP files with the exact same contents (no PHP tags) are served correctly. Could this be an Apache issue?
- With very small files (less than a few kb) I couldn't reproduce the issue.
- Restarting Apache (both using 'sudo apache2ctl restart' or 'sudo apache2ctl stop && sudo apache2ctl start'). No luck.
- Converting line endings from DOS to Unix or Mac type (using nano): the browser receives a truncated file afterwards. Changing back to DOS format gives the same result as before.
- Converting line endings to Unix, then remounting the share, and then editing still gives the same, incorrect results.
- Copying the file to a location inside the native Ubuntu file system (e.g. /var/www/file.css). Works correctly. Changing line endings still gives correct result.
- Reverting back to VBox 3.2.4 (first only the VBox Additions, then the whole application). No luck.

Any clues?

By the way: I started noticing this issue after updating to 3.2.6, but it might have been there before. Earlier, the files were saved inside the VM and shared to Windows using a Samba share, and I didn't have any issues. However, since Netbeans likes indexing files a lot, this caused too much virtual network traffic (and CPU usage peaks) which severely slowed down my system and it thus unwanted.

I'm not really interested in hack-o-matic workarounds/tricks, going back to Samba, removing Windows, or questions like "why don't you use XAMPP instead". I want a real solution. If it's Apache and someone knows the solution, please share it with me, because I couldn't find it. If it's VBox related, please fix it or tell me what I'm doing wrong

Best,
Bart

This might fix your problem: http://forums.virtualbox.org/viewtopic. ... web+server

Wonderful, that worked!

More info can be found on the Apache website:
http://httpd.apache.org/docs/2.0/mod/co ... lesendfile

Apparently it has to do with caching performed by the kernel which affects mounted network shares. Does this mean that it's a kernel problem, or that somehow the mount type (vboxsf in this case) lacks some kind of notification to the kernel which invalidates the cache on change? From my previous attempts it was clear that *some* data got refreshed (at least the file size), but not all (the file contents).

Oh and I agree that a FAQ item on this topic is welcome.

Edit: Hmm according to some sources, it's a limitation of the current sendfile implementation: Presently (Linux 2.6.9): in_fd, must correspond to a file which supports mmap()-like operations (i.e., it cannot be a socket); and out_fd must refer to a socket. See http://linux.die.net/man/2/sendfile and http://tldp.org/LDP/LGNET/91/tranter.html for example.