Shared folder seems to cache old file content for the guest after editing host files

[LigH]

I have VirtualBox 5.0.0 running on a Windows 7 SP1 x64 host, with an Ubuntu MATE 15.04 Linux as guest.

To exchange script files in development, I mounted a share manually to a shared folder ("sudo mount -t vboxsf {sharename} {targetname}", because I did not know where to look for the auto-mounted share), where I copied files to in the hosting Windows, and copied files out of the share into a local directory in the guest Linux.

I found that the script files contained some bugs, which I fixed using Windows tools I have more experience with, which reduced the size of some files (e.g. converting CRLF line breaks to LF only, and deleting some text content).

Then I copied the files with the same name and location in the guest Linux out of the share and into the local directory again, overwriting the old versions of these files. So I thought. But I had to discover that the scripts still contained the buggy parts. And on top, the size was now reduced to the new file size, means, a part of the last script line was truncated now.

The only reliable way to edit the files inside the guest Linux was to empty the files, save with 0 bytes, close, re-open (in gedit or similar fork), then copy the text in a Windows text editor in the host, and paste the text into the Linux text editor via shared clipboard in the guest.

[LigH]

Just tried again. This time, I managed using the auto-mounted shared folder by adding my user to the "vboxsf" group and restarting the guest Linux.

Text file content before editing:

Line 1 with some content.
Line 2 with more content.
Line 3 with even more so.

Copied out of the guest share (/media/sf_{sharename}) into a local directory. File content looks just the same on the host Windows and the guest Linux.

Then edited the text file in the hosting Windows, deleting the first line. Content now on the host Windows:

Line 2 with more content.
Line 3 with even more so.

Copied the file out of the guest share again, overwriting the existing file in the local directory in Linux. Content of the copy in the guest Linux now:

Line 1 with some content.
Line 2 with more content.

Proof: Copy in the local Linux contains the content of the original file before editing, truncated to the new file size after editing.

[LigH]

Updated VirtualBox to v5.0.2. Updated Extension Pack to v5.0.2. Started guest Linux and updated Guest Additions to v5.0.2. Rebooted guest Linux.

Restored text file in the shared directory on the host to the previous content:

Line 1 with some content.
Line 2 with more content.
Line 3 with even more so.

Copied text file in the guest Linux from the auto-mounted shared directory to a local directory.

ligh@ligh-VirtualBox:~$ cp /media/sf_Austausch/~/text.txt ~
ligh@ligh-VirtualBox:~$ cat text.txt
Line 1 with some content.
Line 2 with more content.
Line 3 with even more so.
ligh@ligh-VirtualBox:~$ 

Deleted the first line in the shared text file on the hosting Windows:

Line 2 with more content.
Line 3 with even more so.

Copied the file again from the mounted shared directory to a local directory in the guest Linux:

ligh@ligh-VirtualBox:~$ cp /media/sf_Austausch/~/text.txt ~
ligh@ligh-VirtualBox:~$ cat text.txt
Line 2 with more content.
Line 3 with even more so.
ligh@ligh-VirtualBox:~$ 

Using cp in a console, it works as expected.

Doing the same in the Caja (a Nautilus clone) file manager, though, creates the wrong content:

Line 1 with some content.
Line 2 with more content.

So this bug may not primarily be caused by VirtualBox. I'll try to get in touch with developers of the Ubuntu MATE OS.

[LigH]

Possibly similar issues: ticket:9069 / ticket:9276

I wonder if it is related to not updating one of several file timestamps (e.g. "last modified").

[tim61]

I am seeing similar problems with 5.0.10

Windows 2012 Server is host, Centos 6.7 is guest latest VirtualBox extensionts installed (VBOXADDITIONS_5.0.1.104061

two shares configured via the 'Shared Folders' settings in VBox - both are auto-mount and have access set to 'full', permissions configured correctly (users are members of vboxsf) and no problems encountered writing to the shares

one of the shares has some directories containing JavaScript and CSS which are visible (via symlinks) to Apache. Updates to these files are not reliably seen by Apache - This appears to NOT be an Apache issue, since restarting the httpd process doesn't make the updates visible. So far, the only reliable way to recover (after I've seen that the changes haven't propagated correctly) is to restart the VM. Issues 9069 and 9276 both appear to be in play here - in at least one case, the new version of one affected file was about 500 bytes larger than the previous version - and the version delivered by Apache appears to contain the earlier version's content... padded out with nulls to (close to) the new version's size. The difference wasn't exact, but it was close (I didn't do the math, but the line count could be in play also, given line terminator differences (LF vs CRLF) between guest and host