Caja copies outdated content from VirtualBox shared folder
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Virtualbox |
New
|
Undecided
|
Unassigned |
Bug Description
I have Ubuntu MATE 15.04 running as guest in VirtualBox 5.0.2 (with ext.pack) on a Windows 7 SP1 64b host. There is a shared folder which is automatically mounted to /media/sf_Austausch since I installed the VirtualBox Linux Guest Additions via sudo, and I added the logged-in user to the group of VirtualBox share users (vboxsf) to achieve access to it.
I can copy a simple text file from the shared folder to the local home, via cp in the console as well as via the Caja file manager.
Original content of the text file:
+----
Line 1 with some content.
Line 2 with more content.
Line 3 with even more so.
+----
ligh@ligh-
ligh@ligh-
Line 1 with some content.
Line 2 with more content.
Line 3 with even more so.
Now I edit the content of the shared file on the host Windows by removing the first line.
New content of the text file on the host Windows:
+----
Line 2 with more content.
Line 3 with even more so.
+----
When I copy the file again in the console with cp, the content of the local copy is correct:
ligh@ligh-
ligh@ligh-
Line 2 with more content.
Line 3 with even more so.
But when I copy the same file from the shared folder to the local home again, using Caja this time, the local copy will contain the old content (starting with line 1), truncated at the new file size:
+----
Line 1 with some content.
Line 2 with more content.
+----
So I wonder if there is any reason for Caja (and possibly the original Nautilus project as well) to cache the file content because it does not recognize the file having changed in the meantime. Specifically I wonder if VirtualBox is to be blamed at least partially; there seem to be a lot of issues during the last years, related to corrupt files and the VirtualBox shared directory, regarding programs not correctly recognizing files having changed.
See also: https:/
no longer affects: | ubuntu-mate |
I tried it with just simply adding two characters to the first line ie abcde --> abcdefg while leaving the next two lines alone.
On a Linux host + Linux guest I get the same behavior. But what is interesting is that instead of the resulting pasted file containing abcdefg, what happens is two ascii null bytes (00 in hex) are appended to the end of the file. That is why when the copied file is opened in Pluma, it shows corrupted.
Either way, seems bizarre. I need to understand better how Caja implements copy..paste.