C# Path.GetTempFileName -- 目录名无效

Path.GetTempFileName -- Directory name is invalid

提问by Douglas Anderson

Running into a problem where on certain servers we get an error that the directory name is invalid when using Path.GetTempFileName. Further investigation shows that it is trying to write a file to c:\Documents and Setting\computername\aspnet\local settings\temp (found by using Path.GetTempPath). This folder exists so I'm assuming this must be a permissions issue with respect to the asp.net account.

遇到一个问题，在某些服务器上，我们会在使用 Path.GetTempFileName 时收到目录名称无效的错误。进一步调查显示它正在尝试将文件写入 c:\Documents and Setting\computername\aspnet\local settings\temp（通过使用 Path.GetTempPath 找到）。该文件夹存在，所以我假设这一定是与 asp.net 帐户有关的权限问题。

I've been told by some that Path.GetTempFileName should be pointing to C:\Windows\Microsoft.NET\Framework\v2.0.50727\temporaryasp.net files.

有人告诉我 Path.GetTempFileName 应该指向 C:\Windows\Microsoft.NET\Framework\v2.0.50727\temporaryasp.net 文件。

I've also been told that this problem may be due to the order in which IIS and .NET where installed on the server. I've done the typical 'aspnet_regiis -i' and checked security on the folders etc. At this point I'm stuck.

我还被告知这个问题可能是由于 IIS 和 .NET 在服务器上的安装顺序造成的。我已经完成了典型的“aspnet_regiis -i”并检查了文件夹等的安全性。此时我被卡住了。

Can anyone shed some light on this?

任何人都可以对此有所了解吗？

**Update:**Turns out that providing 'IUSR_ComputerName' access to the folder does the trick. Is that the correct procedure? I don't seem to recall doing that in the past, and obviously, want to follow best practices to maintain security. This is, after all, part of a file upload process.

**更新：**事实证明，提供对文件夹的“IUSR_ComputerName”访问可以解决问题。这是正确的程序吗？我似乎不记得过去这样做过，显然，我想遵循最佳实践来维护安全。毕竟，这是文件上传过程的一部分。

采纳答案by Euro Micelli

This is probably a combination of impersonation and a mismatch of different authentication methods occurring.

这可能是假冒和不同身份验证方法不匹配的组合。

There are many pieces; I'll try to go over them one by one.

有很多片断；我会试着一一复习。

Impersonationis a technique to "temporarily" switch the user account under which a thread is running. Essentially, the thread briefly gains the same rights and access -- no more, no less -- as the account that is being impersonated. As soon as the thread is done creating the web page, it "reverts" back to the original account and gets ready for the next call. This technique is used to access resources that only the user logged into your web site has access to. Hold onto the concept for a minute.

模拟是一种“临时”切换正在运行线程的用户帐户的技术。本质上，该线程会短暂地获得与被模拟的帐户相同的权限和访问权——不多也不少。一旦线程创建完网页，它就会“恢复”到原始帐户并为下一次调用做好准备。此技术用于访问只有登录到您网站的用户才能访问的资源。坚持这个概念一分钟。

Now, by default ASP.NET runs a web site under a local account called ASPNET. Again, by default, only the ASPNET account and members of the Administrators group can write to that folder. Your temporary folder is under that account's purview. This is the second piece of the puzzle.

现在，默认情况下 ASP.NET 在名为ASPNET的本地帐户下运行一个网站。同样，默认情况下，只有 ASPNET 帐户和管理员组的成员可以写入该文件夹。您的临时文件夹在该帐户的权限下。这是拼图的第二部分。

Impersonation doesn't happen on its own. It needs to be turn on intentionally in your web.config.

模拟不会自行发生。它需要在您的 web.config 中有意打开。

<identity impersonate="true" />

If the setting is missing or set to false, your code will execute pure and simply under the ASPNET account mentioned above. Given your error message, I'm positive that you have impersonation=true. There is nothing wrong with that! Impersonation has advantages and disadvantages that go beyond this discussion.

如果该设置丢失或设置为 false，您的代码将在上述 ASPNET 帐户下纯粹且简单地执行。鉴于您的错误消息，我肯定您有 impersonation=true。没有什么不妥！模拟具有超出本讨论范围的优点和缺点。

There is one question left: when you use impersonation, which account gets impersonated?

还有一个问题：当你使用模拟时，哪个帐户被模拟？

Unless you specify the account in the web.config (full syntax of the identity element here), the account impersonated is the one that the IIS handed over to ASP.NET. And that depends on how the user has authenticated (or not) into the site. That is your third and final piece.

除非您在 web.config（此处标识元素的完整语法）中指定帐户，否则模拟的帐户就是 IIS 移交给 ASP.NET 的帐户。这取决于用户如何通过身份验证（或未通过身份验证）进入站点。那是你的第三件也是最后一件。

The IUSR_ComputerName account is a low-rights account created by IIS. By default, this account is the account under which a web call runs if the user could not be authenticated. That is, the user comes in as an "anonymous".

IUSR_ComputerName 帐户是由 IIS 创建的低权限帐户。默认情况下，如果用户无法通过身份验证，此帐户是运行 Web 调用的帐户。也就是说，用户以“匿名者”的身份出现。

In summary, this is what is happening to you:

总之，这就是发生在你身上的事情：

Your user is trying to access the web site, and IIS could not authenticate the person for some reason. Because Anonymous access is ON, (or you would not see IUSRComputerName accessing the temp folder), IIS allows the user in anyway, but as a generic user. Your ASP.NET code runs and impersonates this generic IUSR___ComputerName "guest" account; only now the code doesn't have access to the things that the ASPNET account had access to, including its own temporary folder.

您的用户正在尝试访问该网站，但出于某种原因，IIS 无法对该人进行身份验证。因为匿名访问是 ON，（或者你不会看到 IUSRComputerName 访问临时文件夹），IIS 无论如何都允许用户，但作为一个通用用户。你的 ASP.NET 代码运行并模拟这个通用的 IUSR___ComputerName "guest" 帐户；只是现在代码无法访问 ASPNET 帐户有权访问的内容，包括其自己的临时文件夹。

Granting IUSR_ComputerName WRITE access to the folder makes your symptoms go away.

授予对文件夹的 IUSR_ComputerName WRITE 访问权限会使您的症状消失。

But that just the symptoms. You need to review why is the person coming as "Anonymous/Guest"?

但这只是症状。您需要查看为什么此人以“匿名/访客”身份出现？

There are two likely scenarios:

有两种可能的情况：

a) You intended to use IIS for authentication, but the authentication settings in IIS for some of your servers are wrong.

a) 您打算使用 IIS 进行身份验证，但是您的某些服务器的 IIS 中的身份验证设置是错误的。

In that case, you need to disable Anonymous access on those servers so that the usual authentication mechanisms take place. Note that you might still need to grant to your users access to that temporary folder, or use another folder instead, one to which your users already have access.

在这种情况下，您需要在这些服务器上禁用匿名访问，以便进行通常的身份验证机制。请注意，您可能仍需要授予您的用户访问该临时文件夹的权限，或者改用另一个文件夹，即您的用户已经有权访问的文件夹。

I have worked with this scenario many times, and quite frankly it gives you less headaches to forgo the Temp folder; create a dedicated folder in the server, set the proper permissions, and set its location in web.config.

我已经多次处理过这种情况，坦率地说，放弃 Temp 文件夹会让您不那么头疼；在服务器中创建一个专用文件夹，设置适当的权限，并在 web.config 中设置其位置。

b) You didn't want to authenticate people anyway, or you wanted to use ASP.NET Forms Authentication (which uses IIS's Anonymous access to bypass checks in IIS and lets ASP.NET handle the authentication directly)

b) 您无论如何都不想对人员进行身份验证，或者您想使用 ASP.NET 表单身份验证（它使用 IIS 的匿名访问来绕过 IIS 中的检查并让 ASP.NET 直接处理身份验证）

This case is a bit more complicated.

这个案例有点复杂。

You should go to IIS and disable all forms of authentication other than "Anonymous Access". Note that you can't do that in the developer's box, because the debugger needs Integrated Authentication to be enabled. So your debugging box will behave a bit different than the real server; just be aware of that.

您应该转到 IIS 并禁用“匿名访问”以外的所有形式的身份验证。请注意，您不能在开发人员的框中执行此操作，因为调试器需要启用集成身份验证。因此，您的调试框的行为将与真实服务器有所不同；请注意这一点。

Then, you need to decide whether you should turn impersonation OFF, or conversely, to specify the account to impersonate in the web.config. Do the first if your web server doesn't need outside resources (like a database). Do the latter if your web site does need to run under an account that has access to a database (or some other outside resource).

然后，您需要决定是否应该关闭模拟，或者相反，在 web.config 中指定要模拟的帐户。如果您的 Web 服务器不需要外部资源（如数据库），请执行第一个操作。如果您的网站确实需要在有权访问数据库（或其他一些外部资源）的帐户下运行，请执行后者。

You have two more alternatives to specify the account to impersonate. One, you could go to IIS and change the "anonymous" account to be one with access to the resource instead of the one IIS manages for you. The second alternative is to stash the account and password encrypted in the registry. That step is a bit complicated and also goes beyond the scope of this discussion.

您还有两种选择来指定要模拟的帐户。一，您可以转到 IIS 并将“匿名”帐户更改为可以访问资源的帐户，而不是 IIS 为您管理的帐户。第二种选择是隐藏在注册表中加密的帐户和密码。这一步有点复杂，也超出了本讨论的范围。

Good luck!

祝你好运！

回答by Mark Cidade

You can use Path.GetTempPath()to find out which directory to which it's trying to write.

您可以使用Path.GetTempPath()找出它试图写入的目录。

回答by Gulzar Nazim

Could be because IIS_WPGdoes not have access to a temp folder. If you think it is a permission issue, run a Procmonon asp.net worker process and check for AccessDenied errors.

可能是因为IIS_WPG无权访问临时文件夹。如果您认为这是权限问题，请在 asp.net 工作进程上运行Procmon并检查 AccessDenied 错误。

回答by Mike Gledhill

I was having the same problem with one of my ASP.Net applications. I was getting Path.GetTempPath()but it was throwing an exception of:

我的 ASP.Net 应用程序之一遇到了同样的问题。我得到了Path.GetTempPath()但它抛出了一个异常：

"Could not write to file "C:\Windows\Temp\somefilename", exception: Access to the path "C:\Windows\Temp\somefilename" is denied."

“无法写入文件“C:\Windows\Temp\somefilename”，异常：拒绝访问路径“C:\Windows\Temp\somefilename”。”

I tried a few suggestions on this page, but nothing helped.

我在此页面上尝试了一些建议，但没有任何帮助。

In the end, I went onto the web server (IIS server) and changed permissions on the server's "C:\Windows\Temp" directory to give the "Everyone" user full read-write permissions.

最后，我进入了 Web 服务器（IIS 服务器）并更改了服务器“C:\Windows\Temp”目录的权限，以授予“Everyone”用户完全读写权限。

And then, finally, the exception went away, and my users could download files from the application. Phew!

最后，异常消失了，我的用户可以从应用程序下载文件。呼！

回答by Brian

I encountered this error while diagnosing a console app that was writing in temp files. In one of my test iterations I purged all the files/directories in temp for a 'clean-slate' run. I resolved this self inflicted issue by logging out and back in again.

我在诊断写入临时文件的控制台应用程序时遇到此错误。在我的一次测试迭代中，我清除了 temp 中的所有文件/目录以进行“干净的石板”运行。我通过注销并重新登录解决了这个自己造成的问题。