0

I am running a Red Hat Enterprise Linux 6 (RHEL6) guest VM in VirtualBox installed on my Windows 11 and working on a project located directly inside a VirtualBox Shared Folder (vboxsf).

The enviroment is a Windows 11 with VBox 7.0 and GAs 7.0, with the shared folders bellow.

Shared Folder 1

folder path: C:\Users\myuser\opt\project path name: project mountpoint: /project [ ] Only read [X] Auto mount

Shared Folder 2

folder path: C:\Users\myuser\opt\project\zgames\build path name: buildz mountpoint: /buildz [ ] Only read [ ] Auto mount

The second shared folder I run sudo mount -a to build using the setting bellow on fstab

buildz /buildz vboxsf uid=1001,gid=vboxsf,dmode=777,fmode=666,nofail 0 0

The problem

After insert a file or folder on /buildz or /project using RHEL6, it gets impossible to interacts, I frequently get "text file busy" for remove or edit commands. This problem probably also is the cause for my build errors, because when I build it on RHEL6 inside directories it works, but on shared folders it get some troubles.

cannot remove ios': Text file busy

I tried to change some parameters on fstab line and use git, but it doesn't work.

Improve this question

1 Answer 1

Reset to default
1

Linux (and other POSIX) low level file system functions behave subtly different than Windows.

We can trace a previous discussion on unix.se about vbox shares, to a glib bug trying to understand this from the Linux side cites some software engineering wiki on standards for file I/O in C. In particular, the behavior of a rename when the destination exists is not standard, and on Windows it fails.

VirtualBox file shares presumably map file I/O functions in the guest directly to the host. Various Linux programs you are using try to edit or replace files in the share by a rename, and the Windows file system actually hosting them does the equivalent, but that throws an error.

Native code on both ends is subtly different from code made to deal portably with both. Windows Subsystem for Linux, cygwin, git for Windows with msys2, all have code to run on Windows to some extent. Or a file share like NFS has more POSIX-like behavior.

A workaround could be to do work on the files outside of the share.

  • Create a Linux directory for some scratch space. Wherever makes sense, but for example export BUILDTMP=$(mktemp -d --tmpdir=/var/tmp)
  • Copy or extract from the share to ${BUILDTMP}
  • Do the things
  • Delete previous outputs on the share
  • Copy from ${BUILDTMP} to the share
  • Delete ${BUILDTMP}
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.