-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo add: "failed to persist temporary file: Text file busy" on vboxsf (Linux guest Windows host) #13462
Comments
Thank you for writing down such a detailed report! By reading your trace it's very likely #12744 is the root cuase, though I currently don't have either Virtualbox or Windows at hand to verify. Could you help us bisect if #12744 is really the culprit? If it is, it might be great to file an issue against tempfile and fix the bug there :) |
Rust 1.82 is unable to build any project because of errors like this:
But if I switch to 1.80.1, it builds without errors. |
Could you provide more information of what platform and version you're in? |
@weihanglo It is broken for debug builds very long ago (didn't use them). But release builds are broken in some recent version. |
Debug build is broken like this:
And release version is broken like this:
These versions above are the first with the problem. |
Are you also on Virtualbox with Windows host Linux guest? |
@weihanglo Ah, yes. Windows host, Debian 12 guest, VirtualBox 7.1.4. |
Problem
When the cargo project directory is in vboxsf file system (VirtualBox shared folder) that is shared from host Windows system to guest Linux, then the
cargo add <crate>
command fails with the error:error: failed to persist temporary file: Text file busy (os error 26)
I noticed this after upgrading to rust 1.76.0, but the regression may have been there in 1.75.0 too.
The cargo add was working in older versions inside a vboxsf shared directory.
Steps
Cargo.toml
file is not updated, and a temporary file (e.g.Cargo.tomln1aoHw
) is left into directory.Possible Solution(s)
The regression is probably caused by the change #12744, which introduces
write_atomic
function that uses thetempfile
crate. The tempfile crate assumes "unix semantics", that files can be unlinked and renamed while holding a file descriptor to them. However, in the case of vboxsf filesystem shared from Windows, the files cannot be either renamed or unlinked while having an open file descriptor to them.Debugging with
strace
shows that the rename and unlink calls are done between open and close:Notes
No response
Version
The text was updated successfully, but these errors were encountered: