Windows中是stat还是stati64越野车？

我在我的项目中看到一个奇怪的问题，尽管它存在于磁盘中，但perl无法看到文件。我们通过perl运行一系列短暂的后端作业（每个作业跨越10秒）。后端作业写入输出文件并退出，之后perl进程将尝试传输它。作业最初运行良好，突然无法检测到后端写入的文件。调试perl代码（来自http://www.cpan.org/src/的5.10.1），我发现stati64（win32.c中的win32_stat）失败并返回-1。重试时，通话似乎正常。我可以保证没有后端进程涉及的竞争条件，因为我们试图在后端退出后访问perl中的文件。Windows中是stat还是stati64越野车？

有没有人知道条件（当在短期工作中递归使用）下stat（或stati64）可以说文件不存在，虽然文件存在于Windows？它会缓存先前执行优化的结果吗？

来源

2011-11-01 Kartlee

尝试关闭病毒扫描程序。 –

如果您能够重现该问题，请使用SysInternals Process Monitor（或已弃用但易于使用的Filemon）来查看正在发生的事情。

一个可能的原因是某些其他应用程序（例如防病毒程序或索引引擎）已锁定该文件，但Procmon应显示来自stat的错误代码。

来源

2011-11-01 23:03:00 jdigital

感谢您的回复。我尝试了procmon并捕获了文件活动的事件。这显示文件的stat操作成功 - CreateFile，QueryInformationVolume，QueryAllInformationFile，CloseFile（for stati64）。但是调用的返回值是-1并且GetLastError（）显示6.在选中文件“test_31.01.dat”之前，我们检查filemon显示为不成功的“test_31.01.dat.lock”的存在。这是可以的，因为该文件不存在于代码上下文中。没有像病毒扫描程序这样的外部代理，索引引擎在这里中断。有没有优化问题？ – Kartlee

随着procmon，你是过滤文件名（而不是过程名称）？你想确保检测到任何其他并发访问。另外，问题的一致性如何？如果在什么时候和哪个文件存在变化，那么看起来更像是一种竞争条件而不是优化问题。 – jdigital

是的，它基于文件名。在同一个文件中运行300次，我肯定会得到1-100之间的值。我怀疑自从procmon明确表明身份已经成功以来是否存在竞争状况。我很惊讶为什么返回值只是-1而扩展错误为6。 – Kartlee

如果你想知道你为什么会遇到错误，你应该检查错误信息。它在$!中找到，也许更准确地在$^E中找到。

来源

2011-11-02 06:26:57 ikegami

我最近在不同情况下遇到了一个非常类似的问题。当尝试通过CGI访问文件时，_stati64()将返回-1，并带有ENOENT错误“无此文件或目录”。我编写了一个简单的C程序在文件上运行_stati64()，以查看结果是否相同并且工作正常。

用Procmon进一步调查表明，通过CGI调用的进程在所涉及文件的父目录上的CreateFile操作上会失败;结果始终是ACCESS DENIED，这与尝试访问实际上不存在的文件的结果相同。

的修复结束了以下

使得原本父目录的副本，所有内容
删除原来的
重命名拷贝到原来的名称

是的，我不知道是什么导致了这个问题，但调试起来却是一个非常令人沮丧的问题。我的猜测是CGI访问由于原始目录中的僵化权限而失败。

来源

2012-05-21 10:55:52 rimkojr

Windows中是stat还是stati64越野车？

回答

相关问题