stebalien/tempfile

Temporary file library for rust

tempfile

A secure, cross-platform, temporary file library for Rust. In addition to creating temporary files, this library also allows users to securely open multiple independent references to the same temporary file (useful for consumer/producer patterns and surprisingly difficult to implement securely).

Documentation

Usage

Minimum required Rust version: 1.63.0

Add this to your Cargo.toml:

[dependencies]
tempfile = "3"

Example

use std::fs::File;
use std::io::{Write, Read, Seek, SeekFrom};

fn main() {
    // Write
    let mut tmpfile: File = tempfile::tempfile().unwrap();
    write!(tmpfile, "Hello World!").unwrap();

    // Seek to start
    tmpfile.seek(SeekFrom::Start(0)).unwrap();

    // Read
    let mut buf = String::new();
    tmpfile.read_to_string(&mut buf).unwrap();
    assert_eq!("Hello World!", buf);
}

tempfile's Issues

Allow tempfile to be opened in append mode.

I've recently needed to be able to always write to the end of the file, and it looks like the crate doesn't provide a way to pass the O_APPEND flag to the underlying open call.

Overall, it almost looks like supporting std::fs::OpenOptions in Builder would help fix this, and maybe #30 in a generic fashion.

Release 3.0.0

Due to the changes to the temporary path builder, we'll have to cut a 3.0 release. However, I'd like to avoid a 4.0 release so let's keep track of changes we need to make first:

• Decide on #42.
• Survey uses of tempdir and tempfile for any obvious pain-points.

Add non-clobbering persist method

I'm considering depending on tempfile for https://github.com/untitaker/rust-atomicwrites. While NamedTempFile would fit my purposes, I fear that you might decide to improve security by e.g. keeping an fp open that tracks renames, so that you can remove the file even if renamed.

Could you clarify whether my usecase is valid for this library?

Create a temporary file in a `linux` environment

I'm not following how is the temporary file created in the target_os = "linux" case, the directory seems to be opened but the actual file creation (create_unix) seems to be invoked only in the case of an error.

I'm probably not following this correctly and this is actually a user error, I'm trying to create a file with tempfile::tempfile() but I'm not seeing any file being created (besides the /tmp directory itself being opened) in the strace output (it does work if I change to a non-linux setup), is there a previous configuration I'm missing?

tempfile/src/file/imp/unix.rs

Lines 61 to 81 in ecce519

	#[cfg(target_os = "linux")]
	pub fn create(dir: &Path) -> io::Result<File> {
	use libc::{EISDIR, ENOENT, EOPNOTSUPP, O_EXCL, O_TMPFILE};
	OpenOptions::new()
	.read(true)
	.write(true)
	.custom_flags(O_TMPFILE | O_EXCL) // do not mix with `create_new(true)`
	.open(dir)
	.or_else(|e| {
	match e.raw_os_error() {
	// These are the three "not supported" error codes for O_TMPFILE.
	Some(EOPNOTSUPP) | Some(EISDIR) | Some(ENOENT) => create_unix(dir),
	_ => Err(e),
	}
	})
	}
	#[cfg(not(target_os = "linux"))]
	pub fn create(dir: &Path) -> io::Result<File> {
	create_unix(dir)
	}

PersistError is private

This seems to make it hard to match on errors from persist, or perhaps my Rust is just not strong enough?

I want to write

    if let tempfile::PersistError(e) = f.persist_noclobber(path) {
        return Err(e.error);
    };

Crate no longer compiles on arm

Breakage caused by this.

 Compiling tempfile v1.1.1
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:23:20: 23:46 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:23         libc::open(try!(cstr(&path)).as_ptr(), O_CLOEXEC | O_EXCL | O_RDWR | O_CREAT, 0o600)
                                                                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:23:20: 23:46 help: run `rustc --explain E0308` to see a detailed explanation
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:35:20: 35:44 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:35         libc::open(try!(cstr(dir)).as_ptr(), O_CLOEXEC | O_EXCL | O_TMPFILE | O_RDWR, 0o600)
                                                                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:35:20: 35:44 help: run `rustc --explain E0308` to see a detailed explanation
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:95:24: 95:54 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:95             libc::open(try!(cstr(&tmp_path)).as_ptr(), O_CLOEXEC | O_EXCL | O_RDWR | O_CREAT, 0o600)
                                                                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/tempfile-1.1.1/src/imp/unix.rs:95:24: 95:54 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to 3 previous errors

Convert NamedTempFile to File

Basically, impl From<NamedTempFile> for File. This is doable but non-trivial. Leaving this here in case anyone is interested in working on it.

Got bitten by Drop impl running to early when passing TempDir to fn(p: impl AsRef<Path>)

Yesterday i got badly bitten by using tempdir() in conjunction with std::process::Command::current_dir(...) . My initial code looked like this:

let tmp_dir = tempdir();
let output = Command::new(bin)
    .current_dir(tmp_dir)
    .output()?;  

with bin doing file operations inside tmp_dir. Unfortunately this did not work, and I received an error along the lines of Os Error 2: No such file or directory.
After beating my head against the screen for some time i thought "maybe the tmp_dir is dropped to early and the directory deleted before bin is run?" so i changed

    .current_dir(tmp_dir)

to

    .current_dir(&tmp_dir)

and my program worked just as intended.
Like the issue title says, this was due to the signature of

pub fn current_dir<P: AsRef<Path>>(&mut self, dir: P) -> &mut Command

Since TempDir implements AsRef<Path> i thought that moving it in would be the right thing to do (i didn't need to access the tmp_dir later in the method after constructing the command). But this lead to Drop impl of TempDir being run after current_dir finished but before the execution of bin.

This kind of mistake can quickly happen, especially since many APIs dealing with Paths are generic over AsRef<Path>.
My question is if this pitfall should be pointed out in the documentation and if so, where the best place would be to do this? I'd like to start contributing to some rust crates and this seems like a really easy thing to do, but which could have saved me some time and nerves :D

I was also thinking if it's possible to prevent this mistake, maybe by changing the AsRef<Path> impl to:

impl AsRef<Path> for &TempDir

but this would be a breaking change.

Edit: I assume all of this applies to TempFile as well.

Is the crate thread safe?

Calling temp_dir() from two different threads at the same time seems to be rather likely to return the same directory name (at least on macOS). Possibly due to reliance on thread_rng?

Document independent temporary file access

Documentation should give an example of how to have multiple independent references to a temporary file.

The project descriptions says "...this library also allows users to securely open multiple independent references to the same temporary file..." There isn't an example and it isn't obvious how the API supports it.

clarification regarding the robustness of `persist()`

Hi, I’m investigating what options there currently are regarding atomic
file writes. Assuming Linux, the common pattern requires that fsync(2)
be called on the file fd before closing, then again on the fd of the containing
directory. AFAICS tempfile omits these fsync calls. Could you please
clarify whether this is by design? For potential users of the crate it would
be helpful to state the guarantees it provides in the readme.

Cf. this thread on the Rust forum: https://users.rust-lang.org/t/safe-way-to-write-file-to-disk/32099.

NamedTempFile without delete

Hi, thanks for this library. It's very handy. I like that it's small and resposible for a single thing. But now I am about to ask a feature, which might not be intended to be implemented. 😄

I am about to implement a program which was written in Python before. Which was creating files in a given dir, with a given prefix and suffix. (But the file name contained random parts.) The files were temporary in a sense, that those were deleted by another process. The Python standard libray has the very same package (tempfile) which has the very similar type (NamedTemporaryFile). Which allows to disable the file removal when the handle is going out of scope.

To get this functionality, I need to reimplement most of what this crate does, but delete the Drop trait implementation. Or I can try to use the persist method, but I need to provide a random name somehow. (Not sure how to do that.)

What do you think: would that be okay to expose a keep() or persist() method on the Builder to ask for not to remove the file? Or how would you crate unique file names in a given directory (with given prefix and suffix)?

Document minimum supported rust version

Failed to build on 1.8.0, but succeeds on 1.9.0. This is part of nix's desire to specify a minimum rust version.

It would be good to have this minimum version tested on all CI architectures.

Restore default permissions on persist (on Unix)

Like #2 and #3, it would be nice to get a normal file after calling persist on a NamedTemporaryFile. NamedTemporaryFile is opened with 0o600, I'd expect to get a 0o644 file after that.

Errors from creating files / directories should include the path that was attempted

I've been using tempdir in a project of mine but since that's deprecated in favor of this crate I figured I'd file this issue here.

While trying to track down an issue in Firefox CI I wound up patching tempdir to return the path it tried to create as part of the error message when it failed:
luser/tempdir@bc045d5

Without that patch the error was just "The system cannot find the path specified. (os error 3)" which didn't give me much to work with. With that patch I instead got "Error creating temp directory "z:\build\build\src\c\Users\task_1537988825\AppData\Local\Temp\sccache.HQRR1j9faz6I": The system cannot find the path specified. (os error 3)" which was much more useful.

It would be nice if we could do this in the tempfile crate as well.

should NamedTempFile implement Read/Write on shared references?

I think the standard File implements Read and Write on &'a File (in addition to plan old File) to allow writing through shared references. (I could be understanding this totally wrong, but it seems to work :)) Would it make sense for NamedTempFile to do the same?

Yank 1.1.2, publish 2.0.0

Bumping a minor or patch number breaks downstream libraries when Cargo attempts to link two different versions of the same crate.

Undefined variables in documentation for TempDir::new_in

The docs for TempDir::new_in refer to tmpdir and prefix, neither of which is an argument to the function. tmpdir should probably be dir, but I'm not sure about prefix. The mention of prefix should probably just be removed.
https://docs.rs/tempfile/3.0.2/tempfile/struct.TempDir.html#method.new_in

Provide easy way to get Path of the tempfile.

Hello,
I'd llike to get the Path of the created temporary file. I'm new to Rust, but from what I saw in the docs and in the code of std:fs:File, there is no way to get Path of the open File (this would be nice addition to std, I'll post it on rust reddit for feedback), but in the meantime, it would be nice if you'd return some struct containing the tmpfile's Path and File.

I looked into the internal impl of sys::File, where in fmt::Debug for File there are get_path implementations, but they use the file descriptor to re-read the file path, which is strange, since the File object should have this information :)

Thx.

Close NamedTempFile without deleting

Is there a way to close the file handle without deleting the actual file? On Windows, I have a problem where a child process cannot open the temporary file for reading because the file handle is open by the parent process, resulting in a sharing violation.

The child process (which I cannot change) is opening the file with only FILE_SHARE_READ, not FILE_SHARE_READ | FILE_SHARE_WRITE. According to the Microsoft docs, if FILE_SHARE_WRITE is not specified in the share mode and another process has the file open for writing, CreateFile will fail with a sharing violation. Thus, the only way to fix this is to close the file handle before spawning the child process.

tempfile fails to build against 1.0.0-beta.4

Meta:

rustc 1.0.0-beta.4 (850151a75 2015-04-30) (built 2015-04-30)
binary: rustc
commit-hash: 850151a75709f146addd30bbbf1f23d384f0b381
commit-date: 2015-04-30
build-date: 2015-04-30
host: x86_64-apple-darwin
release: 1.0.0-beta.4

Error during installation:

$ cargo build
   Compiling tempfile v0.2.0
   Compiling cookie v0.1.19
/Users/adinapoli/.cargo/registry/src/github.com-1ecc6299db9ec823/tempfile-0.2.0/src/lib.rs:1:1: 1:34 error: unstable feature
/Users/adinapoli/.cargo/registry/src/github.com-1ecc6299db9ec823/tempfile-0.2.0/src/lib.rs:1 #![feature(convert, from_raw_os)]
                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: this feature may not be used in the beta release channel
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `tempfile`.

Delete stale git branch?

The branches in https://github.com/Stebalien/tempfile/branches/stale haven't been updated for months and some have been merge to master.

There are no reason to keep them.

Choose a writable temp dir please

Reading the docs for the windows temp dir selection, it goes through several fallbacks before it selects a dir:

https://docs.microsoft.com/en-gb/windows/win32/api/fileapi/nf-fileapi-gettemppatha

Would it be possible for this crate to check that the dir selected is writable by the current user before selecting it? ( See rust-lang/cargo#4350 )

Enhance `Builder` to accept as `prefix` or `suffix` any value that implements `AsRef<OsStr>`

Currently the builder allows for prefix and suffix only str, which requires them to be UTF-8 valid. However the underlying code, as the whole Rust standard library, would allow any OsStr to be used.

(If needed I can provide the patch.)

Compile error: cannot find function `create` in module `imp`

Issue

Cant install a dependent library (wasm-bindgen-cli) due to compilation issues in tempfile

Expected Result

cargo install wasm-bindgen-cli runs successfully 🙂

Error Details

traceback in ci

formatted traceback:

error[E0425]: cannot find function `create` in module `imp`
  --> /{{ PATH }}/tempfile-3.0.2/src/file/mod.rs:98:10
   |
98 |     imp::create(dir.as_ref())
   |          ^^^^^^ not found in `imp`
help: possible candidate is found in another module, you can import it into scope
   |
1  | use dir::create;
   |

Environment

• For this Cargo.toml file
• With this build script
• on ubuntu 18.04

(not sure which of those 3 points is most relevant)

tempfile 3.0.9 raises the MSRV

The latest release of tempfile raised its MSRV. That's fine to do, but you should bump your minor version when you do that. Otherwise it breaks downstream builds. Would you please consider yanking 3.0.9 and renaming it 3.1.0?

https://github.com/nix-rust/nix/runs/158960516

use of unstable library feature

After I fixed the create_unix typo, compiling gives me this error on mac OSX:

Nadecinogut:tempfile gabriel$ cargo build
Compiling tempfile v0.5.0 (file:///Users/gabriel/Code/rust/tempfile)
src/imp/unix.rs:26:27: 26:49 error: use of unstable library feature 'from_raw_os': recent addition to std::os::unix::io
src/imp/unix.rs:26         fd => Ok(unsafe { FromRawFd::from_raw_fd(fd) }),
                                         ^~~~~~~~~~~~~~~~~~~~~~
src/imp/unix.rs:105:29: 105:51 error: use of unstable library feature 'from_raw_os': recent addition to std::os::unix::io
src/imp/unix.rs:105                 let first = FromRawFd::from_raw_fd(fd);
                                            ^~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
Could not compile `tempfile`.

My Rust isn't good enough to go in and fix this, or I would. Do you know what might be happening here?

Enhance `NamedTempFile` to allow being "destructured" into both `File` and `TempPath`

Sometimes it is useful to take apart a NamedTempFile and obtaining both a File and a TempPath at the same time.

Currently there is into_file and into_temp_path, but either version "drops" the other one. There is however currently a way to do this without touching this crate but in involves the File::try_clone() function.

(If needed I can provide the patch.)

Figure out how to deal with inaccessible parent directories

So, unix really is lovely...

> mkdir -p /foo/bar
> cd /foo/bar
> chmod a-x /foo
> touch first
> touch /foo/bar/second
touch: cannot touch '/foo/bar/second': Permission denied

As written, this library has the same problem as the second case. We use the absolute path when creating temporary files instead of the relative path. I believe this can actually be an issue in practice with some jails.

Fixing this on linux is doable with openat and unlinkat. Fixing this on osx is possible using per-thread CWDs (at the cost of two extra syscalls to set/unset the thread-local CWD).

PathPersistError is private

Similar to #25 this impacts documentation and ability to write something like:

pub fn commit(self) -> Result<(), _> {                              
  self.temp.into_temp_path().persist(self.path) 
  // found type `std::result::Result<_, tempfile::file::PathPersistError>`
}

Though I'd prefer to stick with std::io::Result here to have it symmetrical with NamedTempFile::new_in().

Unhide windows file on persist.

Allow to create non hidden temporary files (on Windows)

tempfile/src/file/imp/windows.rs

Line 27 in f1273db

const FLAGS: DWORD = FILE_ATTRIBUTE_HIDDEN

I am using winrt-rust and I can't open temporary files with UWP APIs which have hidden bit set (E_ACCESSDENIED). It works if I stop on breakpoint and remove the attribute through explorer (I use NamedTempFile/TempPath).

(Question) How can I read/write with different file handles from/to the same tempfile?

Hello,

I tried the following code:

let f = tempfile()?;
let writer = BufWriter::new(f.try_clone()?);
let reader = BufReader::new(f.try_clone()?);

But this does not work, because writer and reader share the same file, and the reader cannot read any data since the writer moves the file's internal pointer to the end. What I want is to read/write the same file like a queue.

Thanks!

Clarify status on Mac OS X

From the fact you have build badges for Linux and Windows only, should I assume it is not being tested on Mac OS X and may or may not work there?

Update `Builder` (or `create_helper`) to check that the supplied `prefix` and `suffix` don't contain `/`

As the title says, currently the code doesn't make any validations if the prefix or suffix are valid path component values (i.e. they don't contain a slash or \0).

(If needed I can provide the patch.)

Support creating in-memory temporary files

I know this is possible on linux and freebsd. I think it's possible on OS X and Windows. The real question is whether or not to make this a separate type (instead of just TempFile). Also, support a named variant? This would need to be a different type because we wouldn't use actual paths.

Compiling on rust 1.0.0 fails (OSX)

I just tried out gchp/rustbox which uses tempfile and building it failed when compiling tempfile. So I tried to build tempfile itself, same output:

(tried on OSX 10.10.3)

$ git clone [email protected]:Stebalien/tempfile.git
$ cd tempfile
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.1.8
   Compiling rand v0.3.8
   Compiling tempfile v0.3.0 (file:///Users/lnwdr/Desktop/temp/tempfile)
src/imp/unix_common.rs:3:5: 3:33 error: use of unstable library feature 'from_raw_os': recent addition to std::os::unix::io
src/imp/unix_common.rs:3 use std::os::unix::io::FromRawFd;
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/imp/unix_common.rs:32:27: 32:49 error: use of unstable library feature 'from_raw_os': recent addition to std::os::unix::io
src/imp/unix_common.rs:32         fd => Ok(unsafe { FromRawFd::from_raw_fd(fd) }),
                                                    ^~~~~~~~~~~~~~~~~~~~~~
src/imp/unix.rs:50:29: 50:51 error: use of unstable library feature 'from_raw_os': recent addition to std::os::unix::io
src/imp/unix.rs:50                 let first = FromRawFd::from_raw_fd(fd);
                                               ^~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
Could not compile `tempfile`.

To learn more, run the command again with --verbose.

Failed to compile with rust-1.0 stable

Could you remove the unstable feature, so it can compile with rust-1.0 stable

Old documentation on homepage

Summary

The Documentation link on this crate's Homepage leads to an old version - http://stebalien.github.io/tempfile/tempfile/.
The exact one is not specified there, although it's definitely before v3.0.0, meaning at least from 1.5 year ago.

How to stumble upon it

You may think it's hard to find the outdated docs, but it's quite the contrary. I wanted a way to create a temporary directory in Rust, so I searched on crates.io. I found tempdir, but it declared deprecation in favor of tempfile. I then went to its page on crates.io, clicked on Homepage (notice it's the first link under the title), then on Documentation (again the first link). I was really confused when it didn't contain any method for creating temporary directories.

Unset temporary file attribute on windows on persist.

Specifically, when converting to a path (into_path) and persisting (persist), we should probably use SetFileAttributes to unset the temporary attribute.

Provide a way to convert a TempFile into a regular named file (via hard links)

May need to have the availability of this interface be os dependent, not sure it jives with how windows works.

Please support creating temporary directories with mode 0700

tempfile creates temporary files with mode 0600, but doesn't seem to restrict permissions on temporary directories at all. I'd like to create a temporary directory with mode 0700 (and not rely on the current umask to restrict write access). Ideally, I'd like tempfile to do so by default, for security reasons; if there's some reason the default permissions can't change, then I'd like to have an option to set them.

use persist() instead of into_path() for temporary directories

I opened this issue at rust-lang-deprecated/tempdir#44 and was requested to open it here instead.

I have copy/pasted the original issue below:

---

Feature Request

This is a feature/API change request to rename into_path() to persist(), while deprecating into_path().

Reasoning

While I understand the logic behind calling it into_path() (since it "converts" the temporary directory into an "ordinary path"), into_path() actually performs an action from the programmers point of view, namely it removes the invariant that the temporary directory will be deleted on drop.

This is made even more confusing by the documentation, which says: "This destroys the TempDir without deleting the directory represented by the returned Path." -- from a lingual point of view it sounds like we are destroying the directory

Solution

/// Consumes the `TempDir` object without deleting the directory, 
/// returning the `PathBuf` where it is located.
///
/// The directory will no longer be automatically deleted.
fn persist(self) -> PathBuf { self.into_path() }

Enhance `Builder` to allow specifying a parent folder

Although Builder has methods to create temporary entities in a given folder via *_in variants, it would sometimes be useful to be able to specify the parent just as one specifies the prefix and suffix.

I gather this is a trivial change, although must change the lifetime signature of builder to include the newly introduced dependency.

(If needed I can provide the patch.)

what this error: help: a similar path exists: `self::tempfile`

error[E0432]: unresolved import `tempfile`
  --> src/iota/view.rs:17:5
   |
17 | use tempfile::tempdir;
   |     ^^^^^^^^ help: a similar path exists: `self::tempfile`

warning: unused import: `command::Operation::Insert`
 --> src/iota/command.rs:3:5
  |
3 | use command::Operation::Insert;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default

warning: unused import: `std::path::Path`
 --> src/iota/view.rs:3:5
  |
3 | use std::path::Path;
  |     ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `iota-editor`.

I am new to rust, does anyone knows what this means?

Why does TempFile not support access to the underlying File?

I don't care/want/need to persist the file since I am using it for testing, but I want to run operations that are defined on the File type specifically on the TempFile. I can make a PR for accessor methods if they are desired, but their absence seems intentional to me so I figured I'd ask first.

Temporary directories

Allow creating temporary directories and provide methods for securely creating/opening files under them.

Creating NamedTempFile fails on WIN10

Rust:
Stable and nightly

OS:
Win10 Pro N V 1803 build 17134.48

tempfile version = 3.0.0 -> 3.0.2

The code:

extern crate tempfile;

use tempfile::NamedTempFile;
use std::path::{Path, PathBuf};
use std::fs::File;
use std::io;

fn main() -> Result<(), io::Error> {
    let tempfile = NamedTempFile::new()?;
    let file = PathBuf::from("C:\\Users\\deedasmi\\AppData\\Local\\Temp\\.tmpaf6Oxx");
    // Works
    println!("Attempting {:?}", file);
    let out = File::create(file)?;
    println!("Wrote file");
    //Fails
    println!("Attempting {:?}", tempfile);
    let out2 = File::create(tempfile)?;
    println!("Wrote tempfile");
    Ok(())
}

Produces output:

Attempting "C:\Users\deedasmi\AppData\Local\Temp\.tmpaf6Oxx"
Wrote file
Attempting NamedTempFile("C:\Users\deedasmi\AppData\Local\Temp\.tmpOexKbT")
Error: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }

Can tempfiles be read by other users on the system?

Sorry for what might be a dumb question, but can tempfiles be read by other users on the same system?

permissions error with NamedTempFile on Windows 10

It's possible I'm just misunderstanding how files work on Windows, but I'm hitting a permissions error on Windows 10 running under VirtualBox, which also seems to come up on AppVeyor (noisy example). I haven't yet tested on a physical machine. The following fails at the expect:

#[test]
fn test_write_to_closed_path() {
    let named = tempfile::NamedTempFile::new().unwrap();
    let path = named.into_temp_path();
    // The file handle should be closed now, but nonetheless the following fails.
    fs::write(&path, b"foobar").expect("write fails");
}

It does succeed on my Linux machine, though, and on Travis. Also if I explicitly drop(path) before the final line, the final line will succeed on Windows. Something about explicitly removing the file solves the issue?