Description:

See steps to reproduce below for detailed description, however it seems to be Arch Specific, Ubuntu is not affected which means it's a packaging/configuration issue rather than a Virtualbox or Kernel problem specifically.


Steps to reproduce:

Set up VirtualBox with a 64 bit Arch Guest (Haven't tried 32 but assume it would be the same). The host doesn't matter, I have replicated the issue on both an Arch Linux host and a Windows 7 host.

Firstly set up the shared folder for the VM then:

1) GUEST: mount a shared directory: mount -t vboxsf share_name /media/share

2) GUEST: cat /media/share/existing.file <-- Works perfectly, displays the contents of the file from HOST

3) HOST: Write new.file into the shared folder:

4) GUEST: cat /media/share/new.file <-- Works perfectly, displays contents of newly created file

5) GUEST: stat /media/share/non-existing.file <-- As expected displays "no such file or directory"

6) HOST: Write non-existing.file to the shared directory

7) GUEST: cat /media/share/non-existing.file <-- THIS SHOULD WORK NOW AS THE FILE EXISTS BUT INSTEAD SHOWS "No such file or directory"

When typing ls /media-share it shows the file with ??? for permissions, dates, etc.

If the file is written on the host BEFORE trying to access it on the guest it works as expected. If the guest tries to read the file prior to it's existence, the fact it doesn't exist is cached and the guest cannot see the file after it's been created.

This is the same for both windows and linux hosts with an arch guest.

Running echo 3 > /proc/sys/vm/drop_caches to clear the file cache seems to fix it insofar as it will make currently inaccessible files accessible. Any new files affected won't be fixed until the command is run again.

As far as I can tell it's an issue with the file cache. I've tried recompiling the guest's kernel with various options for CONFIG_FSCACHE (arch defaults to =m and the module is not loaded on the guest)

Is there a fix for this? Although I could run drop_caches command in a cron to periodically reset the cache, this is clearly a workaround rather than a fix. I would like a better solution ideally.