Description

On a Win7 x64 host and Ubuntu 11.04 x64 guest, whenever I rename a shared folder directory, the guest OS loses references to the files therein. The files are still there (and correct on the host OS) but somehow inaccessible on the guest: ls shows the filename, but gives "no such file or directory" errors for each file therein (so it would appear that it's there in the filesystem tables, but the pointer to the actual location has got broken somehow). This therefore definitely appears to be a vboxsf error.

The file access can be "restored" by remounting the folder, or by renaming the folder back to its original name. The error always occurs, however the renaming is done (console or file manager). It also occurs if the folder is renamed on the host.

This is a pretty serious error, especially because many apps put things in hidden folders and then rename these (e.g. backup utilities such as Unison).

Change History

To clarify, below is sample reproduction on console (the "ls shows the filename" in the original text is talking about the Linux command ls (el-es), though it's formatted like the word "Is" (capitalised is)!

I have the same problem with 4.0.8 as well as 4.0.4 (but the last one with 4.0.8 additions on the guest, so maybe the problem is in the additions). I experienced the bug running linux 64 bits as both host and guest. After renaming a directory, if I do ls of the contents of the directory I can see the file names but the dates and attributes are all ????, so I guess stat() fails.

Some additional info: this didnt happen with older additions, started happenning in 4.0.4 or 4.0.8 (I'm not sure which). Here's again another example run in a linux 2.6.39 64bits guest with additions 4.0.8:

I think this is Ubuntu 11.04 guest only though, so guest should still say "Linux." I have a Centos 5.6 host with multiple guest OS' accessing the same shared folder. I've got Ubuntu 10.04, 10.10 and 11.04 and only the 11.04 exhibits this problem.

I can confirm this happens with a 32-bit Ubuntu 11.04 guest on a Windows XP host.

The behaviour that led me here is as follows: the guest has access to the shared folder's subdirectories and contents. The host has also published the shared folder over the local network. I then add directories to the shared folder from a remote machine. Result: the guest's Nautilus does not see the new directories. However ls does show the new directories in red along with an error "ls: cannot access x: No such file or directory". A reboot of the guest is required to fix this.

Note that if the host directly creates a folder in the shared folder, the guest updates correctly. If the host renames the red folder, the guest sees it upon refresh. If the host then renames the folder back to its original "red" name, it becomes inaccessible again. But if the *guest* does the renaming, the problem is resolved...for that folder only: any subfolders remain red. The same applies to files (they must be renamed by the host then the guest to fix the problem).

Even stranger, the problem does not arise every time: after rebooting the guest, I tried remotely creating a folder again...and it refreshed just fine.