Skip to content
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

NamedTempFile cannot persist to another NamedTempFile on Windows #131

Closed
acheronfail opened this issue Oct 20, 2020 · 3 comments
Closed

Comments

@acheronfail
Copy link

acheronfail commented Oct 20, 2020

I have tests in my application which create temporary files, write to them, and then persist them. These tests fail on Windows with a Permission Denied error.

A small reproducible example is:

use std::io::Write;
use std::fs;

fn main() {
    let mut t1 = tempfile::NamedTempFile::new().unwrap();
    let mut t2 = tempfile::NamedTempFile::new().unwrap();

    t1.write_all(b"Hello, World!").unwrap();
    t2.write_all(b"Another file").unwrap();

    let t1_path = t1.path().to_owned();
    let t2_path = t2.path().to_owned();
    t1.persist(&t2.path()).unwrap();

    println!("t1: {}", fs::read_to_string(&t1_path).unwrap());
    println!("t2: {}", fs::read_to_string(&t2_path).unwrap());
}
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: PersistError { error: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }, file: NamedTempFile("C:\\Users\\ACHERO~1\\AppData\\Local\\Temp\\.tmptOXOzo") }', src\main.rs:13:28
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\tmp.exe` (exit code: 101)

Is this the intended behaviour? I am unfamiliar with Windows development in general, and by the looks of the other issues here it seems permissions errors aren't exactly uncommon.

@Stebalien
Copy link
Owner

Stebalien commented Oct 20, 2020 via email

@acheronfail
Copy link
Author

On windows, you can't overwrite an open file

I literally just figured this out maybe a minute before you replied!
By dropping the File object it's fixed.

What's your use-case?

My application performs an atomic replacement of a file. My specific use-case for this issue was during my unit tests, where I create "fake" files with tempfile, and then the app proceeds to create its own temp files (again with this crate) and tries to .persist() over them.

The issue was that I hadn't closed the File, so this is my fault, not the crate's!

@Stebalien
Copy link
Owner

I'm glad you found the issue. Windows... takes some getting used to (although, honestly, the extra control over file sharing between applications is actually kind of nice).

martinvonz added a commit to martinvonz/jj that referenced this issue Jun 14, 2021
…file

On Windows, it seems that you can't rename a file if the target file
is open (Stebalien/tempfile#131). I think that's the reason for our
failing tests on Windows. This patch adds a simple wrapper around
`NamedTempFile::persist()` that returns the existing file instead of
failing, if there is one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants