System.IO.IOException:"文件存在"时使用System.IO.Path.GetTempFileName() - 解决方案?

Ome*_*viv 75 .net c#

我的一个客户在尝试使用我的产品时遇到了异常.我获得了发生的异常的callstack,其顶部是:

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.__Error.WinIOError()
   at System.IO.Path.GetTempFileName()
   at System.Windows.Input.Cursor.LoadFromStream(Stream cursorStream)
   at System.Windows.Input.Cursor..ctor(Stream cursorStream)
Run Code Online (Sandbox Code Playgroud)

谷歌搜索这个,我发现很多博客文章说明当%TEMP%文件夹中有超过65535个临时文件时会抛出此异常,并且解决方案是简单地清除旧的临时文件.我可以要求客户这样做,但这可能只是一个临时的解决方案 - 如果他们经常运行其他一些软件,经常调用GetTempFileName,这将使问题一遍又一遍地重复出现?

我不能只是以编程方式清除%TEMP%文件夹,因为这可能会以某种方式损坏其他东西,我无法避免调用GetTempFileName(并使用我自己的临时文件夹),因为它不是我,而是WPF代码正在调用它.

这有什么永久的解决方案吗?

更新:我已经确认%TEMP%文件夹溢出日志文件的问题不是由我自己的代码引起的,而且必须由客户机器上的其他第三方应用程序引起.我也查看了实现,Cursor.LoadFromStream它肯定没有错 - 它生成一个临时文件,但然后在finally块中删除它.

Ger*_*oli 23

如果您在生产环境中或使用无法更改的应用程序发生这种情况,则快速解决方法是清空Temp文件夹.

根据运行应用程序的用户,您应该

  • 为空C:\Windows\Temp(对于IIS或在LocalSystem帐户下运行的服务)
  • 或者%temp%对于本地登录的用户(对我而言C:\Users\MyUserName\AppData\Local\Temp).

另一方面,如果你自己的代码抛出这个,你想要再次发生这种情况:

  1. 不要使用System.IO.Path.GetTempFileName()!

GetTempFileName()二十年前的Win32 Api的包装.它生成的文件名很容易发生碰撞.它通过在文件系统上大量循环,将可能的文件名迭代"%temp%\tmp0000.tmp""tmpFFFF.tmp"跳过现有的文件系统来绕过这些碰撞.这是一个I/O密集,缓慢,坦率的可怕算法.同样仅使用4个十六进制字符是在失败之前对65536文件进行人为限制的原因.

另一种方法是生成不会发生冲突的文件名.例如,让我们重用GUID's逻辑:32个十六进制数字几乎不会碰撞.

private string GetTempFileName()
{
    return Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
}
// Sample: c:\Windows\Temp\2e38fe87-f6bb-4b0d-90b3-2d07016324c1
Run Code Online (Sandbox Code Playgroud)

这将极限从65k扩展到4k百万个文件(理论上)......当然,泄漏65k文件已经很糟糕了,所以...

  1. 不要泄漏临时文件!

仔细检查您的应用程序是否有所有快乐和不快乐的路径(如意外的异常).确保它正确处理每个FileStream并删除Finally块中的临时文件.

  1. 清理临时文件夹

立即清理它,并教育系统管理员定期清理它,因为你无法信任野外的每个应用程序.在我自己的服务器上,我将使用以下方法自动执

  • 对于全球Windows\Temp

schtasks /Create /TR "cmd /c call DEL /F /S /Q %^TEMP%" /TN "Delete Global Temp Files" /sc WEEKLY /ST 12:00 /ru system

  • 对于当前用户:

schtasks /Create /TR "cmd /c call DEL /F /S /Q %^TEMP%" /TN "Delete %username% Temp Files" /sc WEEKLY /ST 12:00


Say*_*yse 14

正如我在上一篇评论中提到的,我认为你唯一安全的方法是询问用户是否要删除文件并重试.你必须让用户输入这个,这样他们自担风险.在我脑海里它的东西类似于.

public Stream GetStream(Stream cursorStream)
{
    try
    {
       //getting stream
    }
    catch(IOE)
    {
        MessageBox.Show(this, "Unable to get stream, your temporary
                              folder may be full, do you want to try deleting 
                                some and try again?");
         if(yes)
         try
         {
             //delete and try again
             return GetStream(cursorStream);
         }
         catch(IOE)
          {
                //no luck
           }
          else
              return null;
    }

}
Run Code Online (Sandbox Code Playgroud)

可选的检查,以确保可以,

Directory.EnumerateFiles(Path.GetTempPath(), "*", SearchOption.TopLevelOnly)
  .Count() == ushort.MaxValue;
Run Code Online (Sandbox Code Playgroud)

  • 我建议你去尝试一下.您建议的布尔测试实际上是错误的 - %TEMP%文件夹中可能还有其他文件,除了GetTempFileName()使用的"tmpXXXX.tmp"格式之外,因此当实际上没有问题时您的测试可能会返回true有问题的时候是假的. (2认同)
  • 可选检查的另一点。当我在构建服务器上遇到这个问题时,临时目录有超过 65535 个文件。该计数仅在创建临时文件的唯一方法是通过 Path 帮助器类时才有效。 (2认同)

Ome*_*viv 5

这是我最后使用的代码,并在我的应用程序的初始化代码路径中提前,在任何Cursor.LoadFromStream可能发生的调用之前:

    private void WarnUserIfTempFolderFull()
    {
        string tempFile = null;
        try
        {
            tempFile = Path.GetTempFileName();
        }
        catch (IOException e)
        {
            string problem = "The Temporary Folder is full.";

            string message = "{ProductName} has detected that the Windows Temporary Folder is full. \n" + 
                             "This may prevent the {ProductName} from functioning correctly.\n" + 
                             "Please delete old files in your temporary folder (%TEMP%) and try again.";

            Logger.Warn(problem);

            MessageBox.Show(message, caption: problem);
        }
        finally
        {
            if (tempFile != null) File.Delete(tempFile);
        }
    }
Run Code Online (Sandbox Code Playgroud)