Temporary file library for rust

Overview

tempfile

Crate Build Status Build status

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.40.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);
}
Comments
  • Merge tempdir api

    Merge tempdir api

    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

    opened by KodrAus 20
  • Add [limited] support for WASI

    Add [limited] support for WASI

    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.

    opened by RReverser 16
  • use persist() instead of into_path() for temporary directories

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

    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() }
    
    opened by vitiral 15
  • tempfile 3.0.9 raises the MSRV

    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

    opened by asomers 14
  • Add non-clobbering persist method

    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?

    opened by untitaker 12
  • permissions error with NamedTempFile on Windows 10

    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?

    opened by oconnor663 11
  • Enhance `Builder` to accept as `prefix` or `suffix` any value that implements `AsRef<OsStr>`

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

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

    opened by cipriancraciun 10
  • Enhance `NamedTempFile` to allow being

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

    opened by cipriancraciun 9
  • use of unstable library feature

    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?

    opened by nihakue 8
  • ref: use SmallRng

    ref: use SmallRng

    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.

    opened by joshuarli 7
  • clarification regarding the robustness of `persist()`

    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.

    opened by phi-gamma 7
  • fix: don't claim 'too many temporary files exist' if a file already existed, once.

    fix: don't claim 'too many temporary files exist' if a file already existed, once.

    Previously when creating a temporary file without any random characters in it, a loop would effectively run once and fail with the conclusion that a file could not be created because too many temporary files exist (2_147_483_648).

    Now it will return the original failure, which typically is that the file with the given name already existed.

    This can more easily happen on case-insentiive file systems, and the correct error message helps understanding what went wrong.

    See https://github.com/Byron/gitoxide/issues/595 for reference.

    opened by Byron 0
  • New release?

    New release?

    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!

    opened by joshtriplett 0
  • feature request: add support for keeping TempDir

    feature request: add support for keeping TempDir

    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.

    opened by ethanpailes 6
  • Maybe setting the permissions of the temporary file is a misfeature?

    Maybe setting the permissions of the temporary file is a misfeature?

    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?

    opened by grahamc 1
  • Replace `fastrand` with `getrandom` and `base64`

    Replace `fastrand` with `getrandom` and `base64`

    • Instead of setting up a predictable userspace RNG, we get unpredictable random bytes directly from the OS. This fixes #178.
    • To obtain a uniformly distributed alphanumeric string, we convert the random bytes to base64 and throw away any letters we don't want (+ and /). With a low probability, this may result in obtaining too few alphanumeric letters, in which case we request more randomness from the OS until we have enough.
    • Because we cannot control the seed anymore, a test manufacturing collisions by setting the same seed for several threads had to be removed.
    opened by vks 8
Minty is an amazingly fast file deduplication app built in rust with a rust user interface.

minty Project Minty has a new look and feel!!! Minty is an amazingly fast file deduplication app built in rust with a rust user interface. I say super

null 26 Nov 20, 2022
Spacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.

Spacedrive A file explorer from the future. spacedrive.com » Download for macOS · Windows · Linux · iOS · watchOS · Android ~ Links will be added once

Spacedrive 15.7k Nov 30, 2022
Zero-details, privacy-focused in-app file system.

ZboxFS ZboxFS is a zero-details, privacy-focused in-app file system. Its goal is to help application store files securely, privately and reliably. By

Zbox 1.4k Dec 2, 2022
the file filesystem: mount semi-structured data (like JSON) as a Unix filesystem

ffs: the file filesystem ffs, the file filessytem, let's you mount semi-structured data as a fileystem---a tree structure you already know how to work

Michael Greenberg 174 Nov 9, 2022
⚡ Garry's Mod module that boosts performance by moving -condebug file I/O to a separate thread

This is a Garry's Mod server module that moves -condebug file I/O out of the main thread, which should significantly improve performance for noisy servers.

William 30 Nov 21, 2022
fftp is the "Fast File Transport Protocol". It transfers files quickly between computers on a network with low overhead.

fftp fftp is the "Fast File Transport Protocol". It transfers files quickly between computers on a network with low overhead. Motivation FTP uses two

leo 4 May 12, 2022
rswatch 🔎 is simple, efficient and reliable file watcher.

rswatch File watcher rswatch is a simple, reliable and efficient file watcher, it can watch a single file or a directory and run arbitrary commands wh

Eugene 3 Sep 23, 2022
Open your operating system's file browser from Garry's Mod.

Open your operating system's file browser from Garry's Mod.

Earu 5 Apr 13, 2022
Rustronomy-fits - a Rustronomy tool for FITS file I/O

Rustronomy-fits - a Rustronomy tool for FITS file I/O Rustronomy-fits provides I/O tools for reading, writing and parsing FITS files. It is currently

Raúl 2 Oct 29, 2022
Dufs is a distinctive utility file server that supports static serving, uploading, searching, accessing control, webdav...

Dufs (Old Name: Duf) Dufs is a distinctive utility file server that supports static serving, uploading, searching, accessing control, webdav... Featur

null 1.7k Nov 29, 2022
Extended attribute library for rust.

xattr A small library for setting, getting, and listing extended attributes. Supported Platforms: Linux, MacOS, FreeBSD, and NetBSD. API Documentation

Steven Allen 33 Nov 12, 2022
A POSIX select I/O Multiplexing Rust library.

A POSIX select I/O Multiplexing Rust library.

b23r0 4 Jul 6, 2022
Expanding opportunities standard library std::fs and std::io

fs_extra A Rust library that provides additional functionality not present in std::fs. Documentation Migrations to 1.x.x version Key features: Copy fi

Denis Kurilenko 161 Nov 25, 2022
High level FFI binding around the sys mount & umount2 calls, for Rust

sys-mount High level FFI bindings to the mount and umount2 system calls, for Rust. Examples Mount This is how the mount command could be written with

Pop!_OS 29 Nov 7, 2022
ergonomic paths and files in rust

path_abs: ergonomic paths and files in rust. This library aims to provide ergonomic path and file operations to rust with reasonable performance. See

Rett Berg 45 Oct 29, 2022
Rust implemention of Ascon

Ascon Pure Rust implementation of the lightweight Authenticated Encryption and Associated Data (AEAD) Ascon-128 and Ascon-128a. Security Notes This cr

Sebastian Ramacher 4 May 28, 2022
Lightweight Google Cloud Storage sync Rust Client with better performance than gsutil rsync

gcs-rsync Lightweight and efficient Rust gcs rsync for Google Cloud Storage. gcs-sync is faster than gsutil rsync when files change a lot while perfor

@cboudereau 4 Sep 8, 2022
Supertag is a tag-based filesystem, written in Rust, for Linux and MacOS

Supertag is a tag-based filesystem, written in Rust, for Linux and MacOS. It provides a tag-based view of your files by removing the hierarchy constraints typically imposed on files and folders. In other words, it allows you to think about your files not as objects stored in folders, but as objects that can be filtered by folders.

Andrew Moffat 536 Nov 22, 2022