Runtime: Add GetRandomFileName that also creates an empty file

Created on 4 Aug 2017  路  5Comments  路  Source: dotnet/runtime

Currently GetTempFileName() creates a file with a random file name but has the limit of ~65K files

The GetTempFileName method will raise an IOException if it is used to create more than 65535 files without deleting previous temporary files.

GetRandomFileName() on the other hand, provides more entropy but

Unlike GetTempFileName, GetRandomFileName does not create a file.

FYI: https://github.com/aspnet/Coherence-Signed/issues/510

An API that provides the "cryptographically strong, random" file name with as much as entropy as GetRandomFileName() but also creates a temporary file like GetTempFileName() can be useful.

cc @Eilon

api-needs-work area-System.IO

Most helpful comment

WPF could use something like this, I think. I like @tmat's suggestion in https://github.com/dotnet/wpf/issues/259 that Path.Combine(Path.GetTempPath(), Guild.NewGuid().ToString()) would be a good starting point.

A new overload for Path.GetTempFileName that works like this might be interesting to consider:

string GetTempFileName(string subFolder)
string GetTempFileName(Guid subFolder)
  • A call to Path.GetTempFileName(Guid.NewGuid()) or Path.GetTempFileName(Guid.NewGuid().ToString()) would generate a temp file under %temp%\<new guid>\.
  • Calling Path.GetTempFileName("contoso") would generate a temp file under %temp%\contoso.
  • It should be possible to specify multi-level folders as well, like Path.GetTempFile("contoso\\corp") to generate a temp file under %temp%\contoso\corp.
  • Path.GetTempFileName(string.Empty) would behave identically to Path.GetTempFileName().

An application using this overload would be free to use a _session GUID_ and create temp files under %temp%\<session GUID>, thus avoiding further pollution of the %temp% folder, and maintaining its own temp files organized under a single folder.

All 5 comments

@jbagga do you propose to make System.IO.Path.GetTempFileName implementation better by avoiding 64K limit, or do you think we need a new API? If you think we need new API, which API name do you propose? (BTW: I find even current 2 API names somewhat confusing - GetTempFileName vs. GetRandomFileName)

do you propose to make System.IO.Path.GetTempFileName implementation better by avoiding 64K limit,

That 64Ki file limit can be good in turning a mistake that thrashes a drive into one that merely throws, so if that approach was taken it might be good to have it opt-in through a new overload.

@karelz Whatever makes more sense for the underlying implementation.

As @JonHanna noted, it may be useful to keep the behavior that throws. So either:

  1. An opt-in overload for throwing at ~65K and improve/increase entropy for GetTempFileName()
    or
  2. A new API that creates a new temp file with more entropy than GetTempFileName() (possible name: GetRandomTempFile() where random implies the "crytographically strong, random")- but I am not picky about the name.

WPF could use something like this, I think. I like @tmat's suggestion in https://github.com/dotnet/wpf/issues/259 that Path.Combine(Path.GetTempPath(), Guild.NewGuid().ToString()) would be a good starting point.

A new overload for Path.GetTempFileName that works like this might be interesting to consider:

string GetTempFileName(string subFolder)
string GetTempFileName(Guid subFolder)
  • A call to Path.GetTempFileName(Guid.NewGuid()) or Path.GetTempFileName(Guid.NewGuid().ToString()) would generate a temp file under %temp%\<new guid>\.
  • Calling Path.GetTempFileName("contoso") would generate a temp file under %temp%\contoso.
  • It should be possible to specify multi-level folders as well, like Path.GetTempFile("contoso\\corp") to generate a temp file under %temp%\contoso\corp.
  • Path.GetTempFileName(string.Empty) would behave identically to Path.GetTempFileName().

An application using this overload would be free to use a _session GUID_ and create temp files under %temp%\<session GUID>, thus avoiding further pollution of the %temp% folder, and maintaining its own temp files organized under a single folder.

Closing as we intend to cover this request in dotnet/runtime#2048.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omajid picture omajid  路  3Comments

aggieben picture aggieben  路  3Comments

EgorBo picture EgorBo  路  3Comments

bencz picture bencz  路  3Comments

iCodeWebApps picture iCodeWebApps  路  3Comments