-
Notifications
You must be signed in to change notification settings - Fork 24
option to keep a temporary directory after panic, for debugging purposes #36
Comments
Personally I think the cases where you'd expect a temporary directory not to be cleared are application specific enough that they're best handled by your application, building an abstraction around struct Directory {
inner: Option<TempDir>
}
impl Drop for Directory {
fn drop(&mut self) {
if let Some(dir) = mem::replace(&mut self.inner, None) {
#[cfg(debug_assertions)]
dir.into_path();
}
}
} |
I took a similar approach to making my life easier shortly after making the issue.
Further making your point, the conditions I chose to leak it on were completely different from yours. I very much want this in release builds! /// Leaks the inner TempDir if we are unwinding.
impl Drop for TempDir {
fn drop(&mut self) {
if ::std::thread::panicking() {
::std::mem::forget(self.0.take())
}
}
} But I do think that panicking is special in this regard. There are many ways you could modify the behavior conditionally on |
Yeh, I see what you mean there. The main thing making me unsure about whether we should support this as a first-class thing in I definitely think we should at least add an example demonstrating how you can avoid dropping the directory when somebody panics like you've shown. |
Isn't it shown at https://docs.rs/tempdir/0.3.5/tempdir/struct.TempDir.html#method.into_path ? |
@otavio: But that does not delete the directory on success, almost entirely defeating the point of making a temp dir (the only remaining advantage being that you don't have to name it). The snippet I linked earlier is an example of the desired behavior, but it is a bit beefy because it makes an effort to do everything that TempDir can. To slim it down a bit: //! Shim around the `tempdir` crate which doesn't delete the
//! directories on unwind, in order to facilitate debugging.
extern crate tempdir;
pub use tempdir::TempDir as ActualTempDir;
use ::std::io::Result;
use ::std::path::{Path, PathBuf};
/// Wrapper around `tempdir::TempDir` that does not destroy the directory on unwind.
#[derive(Debug)]
pub struct TempDir(Option<ActualTempDir>);
// Forward inherent methods to the tempdir crate.
impl TempDir {
pub fn new(prefix: &str) -> Result<TempDir>
{ ActualTempDir::new(prefix).map(Some).map(TempDir) }
pub fn path(&self) -> &Path
{ self.0.as_ref().unwrap().path() }
}
/// Leaks the inner TempDir if we are unwinding.
impl Drop for TempDir {
fn drop(&mut self) {
if ::std::thread::panicking() {
::std::mem::forget(self.0.take())
}
}
} |
I understand but I am unsure it is something we would like to have in production. Possibly, it might be a flag we could configure to enable/disable this behavior. |
What is the "it" you are referring to? The behavior of leaking temp directories, or the presence of a wrapper type around TempDir? If it is the former, that is a problem that can be easily solved by anybody who wants to use this solution in their application. They could easily put the body of the drop impl in a conditionally compiled block. (in fact, this seems a perfect example of the kind of issue @KodrAus is talking about, which shows why this functionality shouldn't be built into the |
@ExpHP yes, leaking temp directories. That's exactly what I had in mind, someone desiring it would have it in a |
Okay. I am closing this because there is a clear case for not building this functionality into the crate, and because I do not feel that the documentation needs to show a solution like this. I feel that somebody who is motivated enough can easily figure it out, and that the presence of the example could create unnecessary confusion. |
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:
and then after a crash occurs, I find the line for the pertinent temp dir, change
path
tointo_path
, and then try to reproduce the crash. I don't think this strategy will scale very well.The text was updated successfully, but these errors were encountered: