Repository navigation
Enhance API to work with temporary files and directories #23538
Description
Rationale
In PowerShell repo we have a feature request to create temporary files with custom extension (not ".tmp").
Also we internally have to implement a function to create a directory for temporary files. Windows has GPO option to create session-based temporary directories.
Creating temporary files/directories is security-related (specially on Unix) so it would be right to implement this in .Net Core.
Unix has very power mkstemps fuction. It makes sense to give users its full functionality.
Proposed API
// if NewSubDir==true create new temporary directory as subdirectory in default temporary directory
public static string GetTempPath(bool newSubDir);
// Create new temp directory in 'InDirectory' directory
public static string GetTempPath(string inDirectory);
// Create a temp file with 'Suffix' extention
public static string GetTempFileName(string suffix);
// Create a temp file in 'InTempDirectory' directory
public static string GetTempFileName(string inTempDirectory);
// Optionally expose Unix 'mkstemps' function features and etc.
public static string GetTempFileName(string prefix);
public static string GetTempFileName(string prefix, string suffix);
public static string GetTempFileName(string prefix, string suffix, int variableLength);
public static string GetTempFileName(string prefix, string suffix, int variableLength, string inTempDirectory);
Activity
svick commentedon Sep 13, 2017
These three can't exist at the same time, since they have the same signature.
(Also, parameters should be named in camelCase, not PascalCase.)
iSazonov commentedon Sep 13, 2017
Thanks for feedback. Case is fixed.
I list all API options for discussiononly - currently I don't know which options is best.
mellinoe commentedon Sep 13, 2017
If this is the case, I think you need to go into more detail about what you expect the behavior to be, and what aspects of the created files you expect to be secure. Do you want the guarantees of
mkstemps, e.g. only the current user and process can access the file?Without security concerns, I think the current API is sufficient -- you could easily build something that creates regular temporary files matching some specified filename pattern.
danmoseley commentedon Sep 13, 2017
@eerhardt for the unix angle
iSazonov commentedon Sep 14, 2017
About security. From link above http://man7.org/linux/man-pages/man3/mkstemp.3.html:
We see two important requirements:
It's not that critical important for Windows but it is best practice too. If we want to create temporary files in an arbitrary directory, it also becomes critical important.
About workarounds. In addition to security, there are technical problems.
If we create a temporary file by standard way and then move it to an arbitrary directory and/or change the extension, we need to resolve the name conflicts: this utility makes millions of attempts in a loop to overcome such conflicts ("File already exists"). This is justified because all processes use a single general directory
/tmp. (On Windows the limit is 65535 files)I guess not all consumers care about these nuances.
We could offer them simple and secure API in .Net Core.
eerhardt commentedon Sep 14, 2017
The Mono.Posix.NETStandard library exposes this function and its corresponding overloads, giving users its full functionality. Of course, it is lower level than the .NET I/O APIs, but you can do anything you'd like.
iSazonov commentedon Feb 11, 2018
Can we expect this unified API to appear in 2.1 version?
JeremyKuhne commentedon Feb 11, 2018
@iSazonov, it is unlikely to be in 2.1 as time is almost up for that release. The enumeration updates are eating up all of my remaining bandwidth. Rest assured that better temporary file handling is something I'm very interested in.
bergmeister commentedon Mar 7, 2018
Another important point is that on Windows it calls an old Windows API for that. This API has not only a limit of around 65.000 files but has also bad performance (especially when getting closer to that limit). Therefore just for the sake of performance and file limit problem a new overload is needed.
JeremyKuhne commentedon Jan 22, 2020
Closing as we intend to cover this request in /issues/2048.