rust-lang-deprecated / tempdir Goto Github PK

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

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

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

cc @rust-lang-nursery/libs

In Stebalien/tempfile#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?

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!

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.

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.

I'm getting rid of duplicate dependencies in my project, and rand 0.4 v 0.7, remove_dir_all 0.5 v 0.6 are one of them.

Examples should use ? instead of either try! or unwrap.

I always find it surprising when methods like join aren't present on TempDir. Is there any reason not to impl Deref<Path> for TempDir here?

Use the commenting convention in BurntSushi/byteorder#78 to tie the html_root_url version to the Cargo.toml version.

Did you consider implementing Deref<Target=Path> and Into<PathBuf> instead of the methods into_path() and path() ?

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

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.

The commit 7874626 broke the build on Rust 1.1. I do not mind, however, I wanted to have it documented somewhere.

This is just a request for a new version of tempdir to be published with the updated version of rand (from #40).

An RFC is required for deprecating nursery crates. There has been no RFC so this crate must be moved back to the nursery.

I have test cases where TempDir fails to remove the directory mysteriously and irregularly.

cc rust-lang/rust#29497

Any reason why TempDir ignores errors when dropped?

I feel this is unsafe default behavior, as it could lead to a long-running process leaking temporary directories. To avoid this problem, a program must wrap TempDir and have the wrapper call TempDir::close in the wrapper's destructor—all to find out that an error occurred.

Here's an alternative. Suppose the TempDir destructor panicks on error instead of silently squashing it. This means a program's default behavior is to be notified of the error. If a program must prevent panicking—for whatever reason—then that program could do the wrapper thing and squash the error in the wrapper's destructor.

The alternative strategy is safer, as it requires action on the part of the programmer to ignore errors instead of requiring action on the part of the programmer to be notified of errors. In the case of TempDir's destructor, an error is probably a leak, the elimination of which is a big part of Rust's raison d'être.

There's no precedent in std for this, and there's been suggestion that the current signature is not correct (preferring &mut self to self).

Tok:tempdir doug$ cargo test
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.1.3
   Compiling log v0.2.5
   Compiling rand v0.1.4
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154:43: 154:52 error: failed to resolve. Use of undeclared type or module `Path`
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154             let reader = try!(File::open(&Path::new("/dev/urandom")));
                                                                                                                               ^~~~~~~~~
<std macros>:1:1: 6:57 note: in expansion of try!
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154:26: 154:71 note: expansion site
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154:43: 154:52 error: unresolved name `Path::new`
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154             let reader = try!(File::open(&Path::new("/dev/urandom")));
                                                                                                                               ^~~~~~~~~
<std macros>:1:1: 6:57 note: in expansion of try!
/Users/doug/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.1.4/src/os.rs:154:26: 154:71 note: expansion site
error: aborting due to 2 previous errors
Could not compile `rand`.

Fix is trivially to use https://github.com/rust-lang/rand, but there doesn't seem to be a working version of rand on crates.io.

Also add the badges to Cargo.toml.

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

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.