File.Delete 删除文件，仍然抛出 UnauthorizedAccessException
在我的 Web 应用程序中，由 IIS 7.5 中的 ASP.NET v4.0 应用程序池托管， 当删除驻留在应用程序所谓的物理路径 (HostingEnvironment.ApplicationPhysicalPath) 中的文件时，该文件会被删除，但仍会引发 UnauthorizedAccessException。
我尝试将该目录的所有权限授予所有用户（用户“Everyone”、用户“ASP.NET v4.0”（这应该是 IIS 7.5 中最重要的用户）、用户“NETWORK SERVICE”， ...），无济于事。
现在，如果我将要删除的文件的路径更改为子目录或磁盘上的任何其他绝对路径，该文件将毫无例外地被删除。
我该如何解决这个问题？
或者，对于网络应用程序来说，从物理路径中删除文件是否被认为是不好的做法（即使它首先将其放在那里，在我的情况下它是一个日志文件）？
更新 与此同时，我通过使用日志文件的子目录来解决这个问题，无论如何，这都是有意义的，但我仍然对为什么会发生该异常以及是否有修复感兴趣。
In my web application, hosted by the ASP.NET v4.0 application pool in an IIS 7.5,
when deleting a file that resides in the app's so-called physical path (HostingEnvironment.ApplicationPhysicalPath), the file gets deleted, but an UnauthorizedAccessException is thrown none the less.
I've tried granting all permissions on that directory to all users (the user "Everyone", the user "ASP.NET v4.0", which should be the one that matters in IIS 7.5, to the user "NETWORK SERVICE", ...), to no avail.
Now if I change the path of the file to be deleted to either a sub directory or to any other absolute path on the disk, the file gets deleted without any exceptions.
How can I fix this?
Or is it considered bad practice for a web app to delete a file out of the physical path (even if it put it there in the first place, in my case it's a log file)?
Update In the meantime, I worked around it by using a sub directory for my log files, which makes sense anyway, but I'm still interested in why that exception occured and if there's a fix.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过说“您向所有用户授予了权限”，您的意思是您使用“Everyone”用户标记了目录吗？如果没有，请检查它是否是基于权限的错误，因为它可能是有趣的 Windows UAC。 UAC 会在未经许可的情况下阻止您写入某些文件夹。
如果您为所有人设置了权限后它就可以工作，请检查应用程序池在哪个用户帐户下运行，并尝试向该帐户授予权限。
By saying 'You gave permissions to all users' do you mean you marked the directory using the 'Everyone' user? If not check that to see if it is permissions based error as it could be the fun windows UAC. UAC stops you writing to certain folders without giving permission.
If it works once you have set the permission to everyone, check to see what user account the application pool is running under and try granting permissions to that account.