Combines the tempdir API, beefs out the docs, and refactors NamedTempFile a bit.

If you'd rather I didn't refactor the internal structure then I can rejig this PR to minimise file movement.

Some previous discussion/iteration on combining the APIs: https://github.com/KodrAus/tempfile/pull/1

cc: @Stebalien @alexcrichton

WASI doesn't have a concept of system-wide temporary directory, but at least there is no reason why new_in methods with explicit paths should fail.

This PR implements support for such methods.

I opened this issue at https://github.com/rust-lang-nursery/tempdir/issues/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() }

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

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?

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?

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.)

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.)

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?

Alternative to https://github.com/Stebalien/tempfile/pull/118.

My understanding is that SmallRng is much smaller and cheaper to initialize than the thread_rng, which is a thread-local ThreadRng (StdRng, with the added overhead of ReseedingRng because it needs to be secure). SmallRng is also faster than StdRng. This is all because SmallRng is not a CSPRNG.

It's worth noting that unreleased rand at this time also shakes rand_chacha from the dependency tree, which is really nice. I believe rand's planning on releasing 0.8, so if this PR looks good, I'd recommend blocking on that. Issues: https://github.com/rust-random/rand/issues/965, https://github.com/rust-random/rand/issues/938.

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::into_file says "The inner file will be deleted".

It's unclear what that means. I'm assuming it means the temp file will be deleted when the Rust File returned by into_file is dropped, but it could also mean that the file will be deleted immediately, but the file handle will still be usable (like in into_parts).

Could you clarify this please?

Getting the following error:

Error: Custom { kind: AlreadyExists, error: PathError { path: "/tmp", err: Custom { kind: AlreadyExists, error: "too many temporary files exist" } } }

When creating a file using the Builder.

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let file = Builder::new().prefix("testsock").rand_bytes(0).tempfile()?;

    Ok(())
}

How can I override the file?

The current state in git has some really helpful new features, particularly the generic version of NamedTempFile. I'd love to build atop that. Would it be possible to get a new release of the current state?

Thank you for working on tempfile!

I would like to be able to conditionally avoid cleaning up a TempDir, and right now there doesn't seem to be an option for that besides resorting to shenanigans to avoid dropping the struct, which would likely lead to some memory leaks. It would be nice to add a disown() method that lets you mark a TempDir or NamedTempFile as not needing to be cleaned up on distruction.

My use case is that I'm using a TempDir as a place to throw some logs during tests and I want to be able to inspect those logs after the fact if I'm iterating on the test by setting an environment variable or something.

Today, tempfile sets the permissions to 0600. When the file is persisted, this mode is then propagated. Unfortunately 0600 isn't a universally applicable mode, especially in cases where the temporary file is being shared with peers on the machine. This is kind-of-but-not-really easy to remedy: programs can chmod the file as they wish.

However, I think it is a mistake to set the mode by default at all.

In order for a program to obey the configured umask, the Rust program has to either parse /proc/self/status for the umask, or set / reset the current program's umask. This second option isn't thread safe, and the first option is a bit yucky too. The program then has to apply the umask and calculate the appropriate bits to chmod the file. There could of course be an error in the duration, leaving a file with an improper mode.

One reason this is such a pain is when libraries I don't necessarily control use and persist a NamedTemporaryFile. Should the libraries do the umask dance? I don't think so: it isn't safe for them to set/reset the umask since they don't know if they're in a multi-threaded environment. I'd rather them not depend on /proc either, since I'd like to use them in environments without /proc if possible.

I've seen various pull requests and issues about this option: approximately a third of the open issues are related to this. I think those options are okay, but what I would really like to see is a function that makes no statements about mode at all and defers to the operating environment of the program:

pub fn create_named_from_umask(path: &Path, open_options: &mut OpenOptions) -> io::Result<File> {
    open_options.read(true).write(true).create_new(true);

    open_options.open(path)
}

Is this something that would be interesting?