virtualbox-ose-additions doesn't seem to want to let go of files placed on a Windows host shared folder.
My host is Win8.1, VirtualBox is 6.1.6, my FreeBSD is 12.1-RELEASE-p3 and my GUI in FreeBSD is Xfce 4.14.
Not sure if this is an issue with FreeBSD or Linux hosts.
Minimal steps to highlight issue:
1. Mount Windows shared folder, for example: sudo mount -t vboxvfs -w Development ~/host
2. Go there in the file manager.
3. Right click "Create Document" -> "Empty File".
4. Then try to delete it. It cannot be deleted.
If you try to delete the file from the command line:
$ rm dog
rm: dog: Text file busy
In fact it cannot be deleted even on the Windows host until the VM shuts down, it's as if the file is still open for writing or something.
This issue came to light running some code that creates lock files, but when done the code was unable to delete the lock files, leaving things in a locked state. Needless to say this is rather annoying.
Derived distros like FuryBSD exhibit the same problem.
(In reply to nixuser from comment #0)
> … as if the file is still open …
You can use fstat(1) in the guest to tell.
man 1 fstat
From the EXAMPLES section of the manual page:
> Requesting information about a file that is not opened results in just a
> header line instead of an error:
A work around:
# mount -t vboxvfs guestshare /mnt
# cp /etc/os-release /mnt
# umount /mnt
# kldunload vboxvfs
Once the FreeBSD VirtualBox guest unload the vboxvfs driver, the host releases its lock on the file in the VBox guest folder.
I think this is a problem on a vboxvfs side. I was able to reproduce it on handful of hosts hosting the test VM (FreeBSD 13 release with 6.1.26 r145957 additions).
/shared is a directory shared from guest to host.
The simple test:
guest:/shared# mkdir d && ls -lad d
drwxrwxr-x 1 root wheel 4096 Sep 13 21:24 d
host:/shared# rmdir d && echo test > d
; has no problem going in
guest:/shared# cd d && ls -la && cd -
-rw-rw-r-- 1 root wheel 5 Sep 13 21:25 .
guest:/shared# cat d
cat: d: Is a directory
guest:/shared#ls -lad d
-rw-rw-r-- 1 root wheel 5 Sep 13 21:25 d
It seems the cache vboxvfs module keeps can get out of sync with the reality pretty fast.
Going through the larger shared directory or even doing ls -la on a shared directory within guest repeatedly renders FS unusable on a guest. Umount/module unload and load back is required to get the functionality back.
>> /shared is a directory shared from guest to host.
I didn't catch this even though I did read after myself. Of course share is coming from host to guest.
Is effectiveness, of things such as vboxvfs, limited by what's possible with FreeBSD?
Bug 258010 comes to mind:
> kqueue shortcoming for desktop usage
My opinion probably doesn't matter due to lack of experience but I don't think that's it.
Few days ago I fixed one bug of random crashes with this module and I was curious to see if I can do more -- understand what is happening and possibly make it better (this module, as many other parts of virtualbox, leaves memory leaks behind).
There seems to be lack of documentation about this or I didn't look well enough.
FreeBSD additions code seems to be inspired by Solaris additions. But in FreeBSD code I see handful of code segments commented out with #if 0 segments. Also the naming seems to be confusing as Solaris is using AVL tree for cache, here simple link list is used.
From what I understand VirtualBox provides API guest can communicate with host. This API is used to get the FS information (vboxvfs_prov.c). The vboxvfs_vnops.c is the glue code. Again, at least how I understood it.
Now I want to find out what happens when there's a change on FS done by host -- how is guest notified and what has to be done.
I'm on my own without any docs, just reading the code. It slow but I'm trying.