获取文件:结果错误

发布于 2024-11-16 17:25:55 字数 686 浏览 2 评论 0原文

我在递归调用中使用以下代码:

var files = di.GetFiles("*.jpg");

di 是传递给函数的 DirectoryInfo。假设某个驱动器 k 的根目录中有一个文件 Tiger.jpg。有时,结果不是 k:\tiger.jpg 而是 k:\iger.jpg。我不知道为什么或如何。有人有过同样的行为吗?

编辑1:即使使用目录名称也会出现这种情况,因为递归函数不会列出子目录中的图像。我认为它主要是 FAT(因为它通常从 SD 卡或 USB 记忆棒等介质读取,有时从 DVD 或 CD 读取)。

每个返回的 FileInfo 对象的全名都使用事件来表示。接收者创建一个新对象,该对象将路径作为构造函数的参数。然后,构造函数调用一个方法,该方法使用该路径来获取有关 jpeg 文件的信息:

FileStream fs = File.Open ( this.Path, FileMode.Open );
Image img = Image.FromStream ( fs, false, false );

这就是异常发生的地方。当我通过调用框架组件获取文件时,我不会再次明确检查它们是否存在 - 我可以将其构建到系统中,但这并不能解决我的问题。

我忘记了一件事:这不会发生在我们的测试系统上,而是发生在全球的系统上:(

I'm using the following code in a recursive call:

var files = di.GetFiles("*.jpg");

di is a DirectoryInfo that is passed in to the function. Assume a file tiger.jpg in the root of some drive k. Occasionally, the result is not k:\tiger.jpg but k:\iger.jpg. I have no idea why or how. Has anyone ever had the same behavior?

Edit 1: It seems to occur even with directory names, because the recursive function does not list images in a subdirectory. I think it is mostly FAT ( because it usually reads from media such as SD card or USB sticks, sometimes from a DVD or CD ).

The fullname of each returned FileInfo object is signalled using an event. The recipient creates a new object that takes the path as an argument to the constructor. The constructor then calls a method that uses the path for getting information about the jpeg files:

FileStream fs = File.Open ( this.Path, FileMode.Open );
Image img = Image.FromStream ( fs, false, false );

This is where the exception occurs. As I get the files from a call to a framework component, I do not explicitly check again if they exist - I can build this into the system, but that does not solve my problem.

One thing I forgot: This does not happen on our test systems, but on a system round the globe :(

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

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

发布评论

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

评论(3

痴梦一场 2024-11-23 17:25:55

可能是错误的稻草,但您是否尝试过转义 \.

k:\tiger.jpg 示例中,C# 会将 \t 读取为选项卡。这实际上不应该发生,但我已经看到它发生了。尝试编写它,以便将所有反斜杠替换为 \\

Could be the wrong straw, but have you tried escaping the \.

In your example of k:\tiger.jpg C# will read the \t as a tab. This shouldn't really happen, but I have seen it occur. Try writing it so that all backslashes are replaced with \\

傾城如夢未必闌珊 2024-11-23 17:25:55

防病毒软件有时会在这里发挥作用。如果您有一个进程生成该文件,而另一个进程正在使用该文件,则可能会出现竞争条件。

不要检查文件是否存在,而是调用 File.Open,然后尝试/捕获 IOException。然后,您需要检查遇到异常时发生了什么。

您永远不能假设文件存在。

至于为什么丢失文件名的一个字母,你是如何生成this.Path的?

Antivirus can sometimes come into play here. If you have one process generating the file and one process that is using it, you may have a race condition.

Rather than checking for the files existence, call the File.Open and then try/catch for an IOException. You will need to then check what's happening when you hit the exception.

You can never assume that a file exists.

As for why you are losing a letter of the file name, how are you generating this.Path?

听风念你 2024-11-23 17:25:55

在这种特殊情况下,似乎是特定的硬件组合触发了一些奇怪的行为。 Win32 API 给出了正确的结果,而 .NET API 返回了错误的结果。

这并不是在所有安装上都能重现。唯一明显的区别是本地化设置,但即使在功能上更改它们也无法帮助我们在本地计算机上进行复制。由于新的硬件版本即将推出,因此没有进一步的调查。

如果您确定已涵盖其他答案中的所有建议并且遇到完全相同的问题,您可能需要联系操作系统供应商。

In this particular case, it seems it was a specific combination of hardware that triggered some weird behavior. The Win32 API brought up correct results while the .NET API returned wrong results.

This wasn't reproducible on all installations. The only obvious difference were localization settings, but even changing them on a functional didn't helped us coming up with a repro on one of our local machines. As a new hardware revision will be rolled out there are no further investigations.

If you're sure you have covered all proposals from the other answers and have the very same problem, you might want to contact the OS vendor.

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