Bug 245865 - emulators/virtualbox-ose-additions doesn't let go of files placed on a Windows host shared folder
Summary: emulators/virtualbox-ose-additions doesn't let go of files placed on a Window...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Virtualbox Team (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-24 03:52 UTC by nixuser
Modified: 2021-09-14 12:10 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (vbox)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nixuser 2020-04-24 03:52:56 UTC
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.
Comment 1 Graham Perrin 2021-07-22 04:24:02 UTC
(In reply to nixuser from comment #0)

> … as if the file is still open …

You can use fstat(1) in the guest to tell. 


fstat /path/to/file


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:
Comment 2 groenveld 2021-07-23 20:23:13 UTC
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.
John
groenveld@acm.org
Comment 3 martin ilavsky 2021-09-13 19:30:49 UTC
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.
Comment 4 martin ilavsky 2021-09-13 19:32:20 UTC
>> /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.
Comment 5 Graham Perrin 2021-09-14 06:41:44 UTC
Is effectiveness, of things such as vboxvfs, limited by what's possible with FreeBSD?

Bug 258010 comes to mind: 

> kqueue shortcoming for desktop usage
Comment 6 martin ilavsky 2021-09-14 12:10:59 UTC
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.