![]() ![]() There are two types of shares: Permanent shares, that are saved with the VM settings. See Section 7.31, VBoxManage sharedfolder add/remove. So my hypothesis is that this is a vboxsf linux module bug: when a file is overwritten, it correctly updates its disk content and its metadata (timestamp, size), but it fails to inform the OS that its cache for this file should be invalidated.ĭid anyone meet something similar? Does my interpretation seem reasonable? I would prefer to discuss this issue here before logging a bug on the tracker. From the command line, you can create shared folders using VBoxManage, as follows: VBoxManage sharedfolder add 'VM name' -name 'sharename' -hostpath 'C:\test'. Interestingly, the only way I found to get the new content was either to reboot the VM, or to perform the following command to empty the OS cache: sync echo 3 > /proc/sys/vm/drop_caches If I perform the same manipulation of a "regular" guest directory, overwrites are taken into account as soon as the web page is reloaded, so this clearly seems related to shared folders. The problem can also be reproduced my overwriting the file using a "cp" command while logged on the Debian guest. I suspected some caching or timestamp issues, but I can only reproduce this behavior on a VirtualBox shared folder. This is quite convenient: the web site can then be edited using host (Windows) tools, while still being served by the Apache server.Įxcepted that the actual behavior is the following: when a file (an image, as an example) is overwritten on this shared folder, Apache still serves the old content. While building a small VirtualBox VM in order to do some web development (a typical LAMP stack on a Debian), I chose to host the apache DocumentRoot on a shared folder. ![]()
0 Comments
Leave a Reply. |