-
Notifications
You must be signed in to change notification settings - Fork 23
Design question: why support just dirs and not files? #19
Comments
At this point it's mostly just historical and not intentional. Long ago we had |
Ooo good to know. I bet a lot of @Stebalien's work on https://stebalien.github.io/tempfile/tempfile could be imported. (There are a bunch of places in those docs where it says "SECURITY WARNING" though, will want to think carefully about those one way or another.) Edit: relevant context https://www.reddit.com/r/rust/comments/32n864/tempfile_temporary_file_library/cqd3ic0/?context=3 |
Sounds plausible to me! |
If we want to merge tempdir and tempfile would it be better to call it |
Is this something you guys would like to do before a cc: @alexcrichton |
It seems like most other languages I've used handle both in one library? New users might find it a little surprising to split them? https://docs.python.org/3.6/library/tempfile.html |
cc me |
Basically, relying on named temporary files in the presence of temporary file cleaners is tricky. However, to be honest, I could probably soften those warnings.
I'd also be happy to give up the tempfile crate name for the greater good. Alternatively, someone could write an fsutil crate for all these miscellaneous filesystem related tools. |
I can think of a few paths forward:
I guess which option makes the most sense depends on how important this is, and whether we're happy to defer stabilising Maybe we should cast the net wider and see if other Rustacean's expect temporary file and directory handling in a single crate? What do you all think? |
I'd be totally down for merging the two crates somehow if desired, it's sort of what I'd expect! I think tempfiles have the nice property that they can almost always have guaranteed cleanup on process exit, whereas temporary directories not so much :( |
Having the one crate with a consistent API for temporary directories and files does sound nice. I'm just not sure how much we should churn users of |
Completely on board. However, I'd really like a directory abstraction that allows one to securely create files/directories under a directory (guaranteeing that the files are actually created under the given directory) and have |
It looks like this is something folks are pretty much on-board with, but it's a pretty significant undertaking. Would a good next step be a pre-RFC to work out specifics like crate name and API? |
I wouldn't necessarily think this needs an RFC, but it probably couldn't hurt if you're feeling up to the task! |
Sure, I'll get the ball rolling on this 👍 |
Added contents_first option Added ability to yield the contents of the directory before the directory itself Fixes rust-lang-deprecated#18
We've now got the I'll go ahead and close this now, and we can continue tracking the progress of a new |
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 :) )
The text was updated successfully, but these errors were encountered: