I'm curious about the reasons for focusing specifically on temp dirs and not temp files. Are there security benefits to always using a dir? Or simplicity/portability benefits? Asking out of historical interest more than anything else. (Apologies if this is an abuse of issues :) )

In https://github.com/Stebalien/tempfile/pull/33 we combined the tempdir and tempfile APIs, with the goal of using the tempfile crate as the source of temporary files and directories going forward.

I've gone through and review the open issues here (and basically just closed them all). I think the next step is to propose deprecating this repository and moving into rust-lang-deprecated, with a note in the readme that tempfile is the place to go for temporary directories going forward.

What do you all think? Is there anything else we should consider?

Suppose that I have some code which works inside of a temp dir, and a bug is detected which causes it to panic. When this occurs, I would like to be able to go look at the temporary directory and inspect the files created leading up to the error. However, during the panic, it will invariably have unwound through the TempDir destructor, and so the directory is gone.

Currently the only real solution I have is to write all of my temp dir construction like this:

let tmp = TempDir::new("my-thing");
let tmp = tmp.path();

and then after a crash occurs, I find the line for the pertinent temp dir, change path to into_path, and then try to reproduce the crash. I don't think this strategy will scale very well.

This is just a request for a new version of tempdir to be published with the updated version of rand (from https://github.com/rust-lang-nursery/tempdir/pull/40).

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() }

These tasks came from the libs team evaluation on 2017-03-20.

• [x] Fix remove_dir_all on windows
• [x] Update examples to use ?
• [x] Add CI for Windows/Mac
• [x] Add keywords and categories to Cargo.toml
• [x] Finalize conventions for close
• [x] Update html_root_url
• [ ] Bump version to 1.0

cc @rust-lang-nursery/libs

When writing tests that need a working directly I've used randomly-named directories a lot. The Python equivalent of tempdir does that by default. I was thinking of the addition of tempdir::new_unique() that would generate a new unique temporary directory.

I'm curious whether tempdir would be interested in adding a RamDir type if it were possible to make such a type.

tmpfs is:

tmpfs is a temporary filesystem that resides in memory and/or swap partition(s). Mounting directories as tmpfs can be an effective way of speeding up accesses to their files, or to ensure that their contents are automatically cleared upon reboot.

It looks like there is a (linux only) libmount that could be leveraged to do the job, although I would prefer using ramfs, as it is guaranteed to be in ram. I haven't looked at that crate, but ramfs could potentially be added there.

It's also at least theoretically possible to support windows, as a tool exists called ImDisk, but this issue is suggesting unix-only support through the tmpfs call (for now).

This issue is mostly to ask whether this feature would be supported by the project devs or whether a new crate should be made instead. Thanks!

Ive been going through our dependencies and I saw that this crate is pre-1.0 and also didn't have a tracking issue for getting there. I wanted to post this to see if there was a plan for getting to 1.0. Considering how few issues have been posted with this crate and how often it's used, I'd think it would be pretty close to a 1.0, so wanted to check in here to see what the maintainers think.

TempDir currently looks like this:

pub struct TempDir {
    path: Option<PathBuf>,
}

And functions rely on it being an Option, ex:

pub fn path(&self) -> &path::Path {
    self.path.as_ref().unwrap()
}
// and
pub fn into_path(mut self) -> PathBuf {
    self.path.take().unwrap()
}

These functions do not take into consideration that the path could be set to None. Currently this is not a problem because fn new_in will never set it to None however many times it will retry to find a random folder name. So, the result is either path(from TempDir) being set to Some(path) or the user receiving Err. In this case, why not get rid of the Option and just set the TempDir { path: } directly to path and return Err otherwise?

If None is planned for feature use, than functions like path and into_path should probably return Option<&path::Path> and Option<PathBuf> instead of unwrapping for the user and panicking.

This of course will bump the library version.

I was just looking through the code("looking for inspiration") and observed a bug that is the equivalent of dangling pointers but with Rust Options(of course, no memory corruption). When calling into_path, path will be replaced with None - then -> if somebody calls the path function, the application will panic(because it unwraps for the user - which would be the equivalent of dereferencing a dangling pointer). I think it's better to break the API(v0.4) and make this function return an Option<&path::Path>, or maybe some other option(solution).