文件系统路径和 Directory.Exists()

发布于 2024-11-18 21:08:04 字数 1421 浏览 2 评论 0原文

我对此有点茫然……似乎无法理解发生了什么。

我有一个应用程序将一些文件写入配置的输出目录,但在此之前,当应用程序加载时,我会执行此操作...

string path = ConfigurationManager.AppSettings["TempDir"];
if (!Directory.Exists(path))
    Directory.CreateDirectory(path);

我的问题是,在我的情况下,路径是基于网络的位置“\MyServer\Share”,并且当我使用它有效的路径,但我使用的路径实际上是“Z:\”,因为共享已映射并自动映射到网络上的所有用户会话中。

我想使用“Z:\”,但它不起作用,会返回“全部或部分路径不存在”的错误。

我立即想到“哦,这一定是权限”,所以我对照说“G:\”进行了检查,它有效并且应用了相同的权限......

对于所有有问题的共享,我的用户帐户对该位置具有完全控制权限。

最初我认为可能是这样的: Directory.Exists 未获取映射目录 但后来我想起该应用程序不可能在另一个帐户下运行,因为我检查过它

  1. 只是一个控制台应用程序
  2. 之前的行是这样的:

    AppDomain.CurrentDomain.SetThreadPrincipal(new WindowsPrincipal(WindowsIdentity.GetCurrent()));
    

.. 据我了解,这样做的目的是确保应用程序域在当前 Windows 用户的上下文中运行,其中包括在应用程序域中创建的所有“线程” “除非另有说明,

有什么想法吗?

编辑:

按照理查德的建议查看进程监视器(请参阅下面的评论)表明,如果我使用完整的 unc 路径“\MyServer\Share”,则请求将按我的预期发出,如果我使用映射路径“Z:\”仍然请求完整的 unc 路径“\MyServer\Share”(大概它正在 .net 的内部工作中进行某种形式的转换)。

所以无论我请求完整的 unc 路径“\MyServer\Share”,但只有通过显式指定完整的 unc 路径我才能访问它......奇怪!

上面发布的代码与我在控制台应用程序中编写的代码完全相同,除了这个原则之外没有其他事情发生,因为这些是在我的控制台应用程序中执行的第一行代码。

嗯...

编辑2:

好吧,现在我真的很困惑,当在上面的配置文件请求行上放置一个断点并将其运行到断点时,然后清除进程监视器并跳过它,并且 if 语句中没有出现任何内容正如我所期望的那样,进程监视器......

为什么会发生这种情况?

I'm at a bit of a loss on this one ... can't seem to understand what is going on.

I have an app that writes some files to a configured output directory, but before that, when the application loads I do this ...

string path = ConfigurationManager.AppSettings["TempDir"];
if (!Directory.Exists(path))
    Directory.CreateDirectory(path);

My problem is that in my case the path is a network based location "\MyServer\Share" and when i use that path it works, but the path i'm using is actually "Z:\" because the share is mapped and is automatically mapped in all user sessions across the network.

I want to use "Z:\" but it doesn't work throwing back an error saying "all or part of the path doesn't exist".

I immediately thought "oh this must be permissions" so i checked it against say "G:\" which worked and has the same permissions applied ...

For all shares in question my user account has full control permissions on the location.

Initially i thought it might be something like this: Directory.Exists not getting mapped directory
But then i remembered that it couldn't be that the app is running under another account because I checked and

  1. its only a console app
  2. the line before is this:

    AppDomain.CurrentDomain.SetThreadPrincipal(new WindowsPrincipal(WindowsIdentity.GetCurrent()));
    

.. as i understand the purpose of this is to ensure that the appdomain is running under the context of the current windows user, that includes all "threads created within the app domain" unless otherwise specified

Any ideas?

EDIT:

Looking through process monitor as Richard suggests ( see comments below) shows that if i use the full unc path "\MyServer\Share" the request is made as I would expect, if i use the mapped path "Z:\" it still requests the full unc path "\MyServer\Share" (presumably it is doing some form of translation in the inner workings of .net).

so no matter what i'm requesting a full unc path "\MyServer\Share" and yet only by explicitly specifying the full unc path can i access it ... weird !!!

The code posted above is exactly as I have written it in my console application, there's no other stuff going on yet other than that principle thing as these are the first lines of code to execute in my console application.

Hmmm ...

EDIT 2:

Ok now i'm really confused, when put a breakpoint on the configuration file request line above and run it up to the breakpoint then clear out process monitor and step over that and the if statement nothing appears in the process monitor as I would expect it to ...

Why would that happen?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

庆幸我还是我 2024-11-25 21:08:04

您不能使用映射驱动器作为创建共享目录所需的路径并为其授予所需的权限(读取或写入),然后像这样连接到它:
\服务器名称\共享目录名称\OneMoreDirectory

You can not use mapped drive as a path you need to make a shared directory and give it the permission you need (read or write) and then connect to it like this:
\ServerName\SharedDirectoryName\OneMoreDirectory

遗忘曾经 2024-11-25 21:08:04

我似乎在调试工具/.net 框架中发现了一个奇怪的错误......
当调试器附加到我的应用程序时,它会失败;当调试器未附加时,它会按预期工作。

建议始终使用完整的 unc 路径,但对 Directory.Exists(path) 和 Directory.Delete(path) 的调用会在调用进程监视器显示之前解析映射驱动器,因此尽管建议这样做,但这不是必需的。

然而,我发现运行应用程序然后手动附加 Visual Studio 似乎允许应用程序按预期运行并允许在我的情况下进行需要调试。

该解决方案仅附带“适用于我的电脑保证”...我对此问题中所说的任何内容不承担任何责任:)

感谢大家的帮助,但我似乎已经解决了它...UAc 是很好的建议,进程监视器也是如此...谢谢大家...真的很有帮助:)

I seem to have found an odd bug in the debugging tools / .net framework ...
When the debugger is attached to my app it fails, when the debugger is not attached it works as expected.

The recommendation is always to use a full unc path but the calls to Directory.Exists(path) and Directory.Delete(path) resolve mapped drives before making the call as process monitor reveals so although it is recommended it is not required.

I have found however that running the app then attaching visual studio manually seems to allow the app to run as epected and allow the require debugging in my situation.

This solution comes with the "Works on my PC garantee" only ... i take no responsibility for anything said in this question :)

Thank you to everyone for the help however I seem to have resolved it ... UAc was good advice and so was process monitor ... thanks guys ... really helped :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文