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: Open
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: https://www.freshports.org/emulators/...
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2020-04-24 03:52 UTC by Ian Laurie
Modified: 2023-08-25 10:50 UTC (History)
4 users (show)

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


Attachments
Patch for ports tree (17.24 KB, patch)
2023-08-25 10:43 UTC, takahiro.kurosawa
no flags Details | Diff
Patch for the vboxvfs module source (VirtualBox-6.1.46/src/VBox/Additions/freebsd/vboxvfs) (10.96 KB, patch)
2023-08-25 10:50 UTC, takahiro.kurosawa
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Laurie 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 freebsd_committer freebsd_triage 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 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 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 freebsd_committer freebsd_triage 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 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.
Comment 7 Graham Perrin freebsd_committer freebsd_triage 2023-08-18 20:21:57 UTC
Reproducible with 6.1.46 additions and 13.2-RELEASE-p2 as a guest?
Comment 8 takahiro.kurosawa 2023-08-25 10:43:08 UTC
Created attachment 244334 [details]
Patch for ports tree

I've run into this problem while playing with shared folders on 14-CURRENT w/ virtualbox-ose-additions-6.1.46.
The patch is tested on 14-CURRENT and 13.2-RELEASE.  Not tested on 12.
Also fixes a bug around directory listing.
Comment 9 takahiro.kurosawa 2023-08-25 10:50:19 UTC
Created attachment 244335 [details]
Patch for the vboxvfs module source (VirtualBox-6.1.46/src/VBox/Additions/freebsd/vboxvfs)

The patch for ports tree tends to conflict due to mismatched contexts.  I'll attach a patch for the vboxvfs module source too.