Directory.CreateDirectory 延迟问题？
我正在尝试创建一个远程目录，然后向其中写入一个文件。每隔一段时间，应用程序就会在尝试写入文件时失败并出现 System.IO.DirectoryNotFoundException。
当我写入文件时，我使用返回的 DirectoryInfo 对象来帮助创建文件路径，因此应用程序似乎认为该目录已创建。但是，该目录不存在。
我是否有可能在 Windows 完成创建目录之前尝试写入该目录？我认为在该任务完成之前 Directory.CreateDirectory 不会返回。
I'm trying to create a remote directory, and then write a file to it. Every great once in a while, the application fails with a System.IO.DirectoryNotFoundException while trying to write the file.
When I write the file, I'm using the returned DirectoryInfo object to help create the file path, so the application seems to think that the directory has been created. However, the directory does not exist.
Is there any chance that I'm trying to write to the directory before Windows has finished creating it? I would think that the Directory.CreateDirectory would not return until this task was finished.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我刚刚遇到了这个问题，对我来说，情况是这样的：
然后，当在另一个类中将这个相同 DirectoryInfo 对象传递给它时，我做了一个：
并且该目录显然仍然不存在（虽然我在 Windows 中打开了父目录，当然我可以在我面前看到它）。
我找到的解决方案是在最初创建我应该调用的目录之后：
来自 Microsoft：
I just had this problem and for me the situation was like this:
Then later when in another class that has this same DirectoryInfo object passed to it I do a:
And the directory apparently still doesn't exist (although I have the parent directory open in windows and of course I can see it right in front of me).
The solution I found is after the initial creation of the directory I should be calling:
From Microsoft:
回答 - 是的。文件/目录创建滞后时的行为是预期的。其他评论者提出的普通解决方案是使用超时重试。无论使用什么文件函数，其行为都是相同的：Findfirst、CreateFile、WaitForSingleObject 等。
另一个解决方案是使用 Vista 和更高版本的 Windows 操作系统上的 API 的新事务函数。
这个问题很棘手，并且在其他平台上制作并迁移到 Windows 的文件密集型项目的开发人员从未理解过：如 DOS/CMD 脚本、SVN 客户端、Cygwin、perl、各种 java 应用程序、各种安装程序等。
Answer - Yes. The behavior, when file/directory creation is lagging is expected. Ordinary solution as proposed by other commenter is to use retries with some timeout. The behavior is the same whatever file functions are used: Findfirst, CreateFile, WaitForSingleObject etc.
Another solution will be to use new transactional functions of API found on Vista and later Windows OSes.
The problem is nasty and was never understood by developers of file-intensive projects made on other platforms and moved to Windows: like DOS/CMD scripts, SVN clients, Cygwin, perl, various java applications, various installers etc.
虽然我从未经历过这种行为并且无法解释它，但一个实用的解决方案是围绕访问目录的调用设置一个循环。在该循环中捕获 DirectoryNotFoundException，并在每次短暂暂停后重试访问几次。如果超过重试次数，则重新抛出异常。
此时添加详细的日志记录可能会帮助您确定问题的实际原因。
While I have never experienced this behavior and cannot explain it, a pragmatic solution is to setup a loop around your call accessing the directory. Catch DirectoryNotFoundException inside that loop, and retry access a few times after a short pause each time. Rethrow the exception if the retry count is exceeded.
Adding detailed logging at this point may help you determine the actual cause of the problem.