我想打开一个由另一个应用程序定期写入的文件。该应用程序无法修改。因此,我只想在知道该文件未被其他应用程序写入时才打开该文件。
有没有Pythonic的方法来做到这一点?否则,我如何在 Unix 和 Windows 中实现这一点?
edit: 我会尽力澄清。有没有办法检查当前文件是否已被其他应用程序打开?
我想从这个问题开始。其他应用程序是否读/写目前无关紧要。
我意识到它可能依赖于操作系统,所以现在这可能与 python 无关。
您的 python 脚本想要打开文件进行写入还是读取?旧应用程序是在写入之间打开和关闭文件,还是保持文件打开状态?
了解遗留应用程序正在做什么以及您的 python 脚本试图实现什么目标非常重要。
该功能领域高度依赖于操作系统,不幸的是,您无法控制遗留应用程序,这一事实只会让事情变得更加困难。无论是否有Pythonic或非Pythonic的方式来做到这一点可能是你最不关心的问题——困难的问题是你想要实现的目标是否可能实现。
UPDATE
好的,所以(从您的评论中)知道:
旧应用程序正在打开并且
每 X 分钟关闭一次文件,但是
我不想假设在 t =
t_0 + n*X + eps 它已经关闭
文件。
那么问题的参数就改变了。它实际上可以在给定一些假设的情况下以独立于操作系统的方式完成,或者作为依赖于操作系统和独立于操作系统的技术的组合来完成。 :)
-
OS-independent way: if it is safe to assume that the legacy application keeps the file open for at most some known quantity of time, say
T
seconds (e.g. opens the file, performs one write, then closes the file), and re-opens it more or less every X
seconds, where X
is larger than 2*T
.
-
stat
文件
- 减去文件的修改时间
now()
,产生D
- if
T
<= D
< X
然后打开该文件并用它执行您需要的操作
-
这对于您的应用程序来说可能足够安全。安全性随着
T
/X
减少。在 *nix 上你可能需要仔细检查/etc/ntpd.conf
正确的时间步进与转换配置(请参阅修补程序)。对于 Windows,请参阅MSDN http://support.microsoft.com/kb/223184
-
Windows: in addition (or in-lieu) of the OS-independent method above, you may attempt to use either:
- sharing (locking): this assumes that the legacy program also opens the file in shared mode (usually the default in Windows apps); moreover, if your application acquires the lock just as the legacy application is attempting the same (race condition), the legacy application will fail.
- 这是非常侵入性的并且容易出错。除非新应用程序和旧应用程序都需要同步访问来写入同一文件,并且您愿意处理旧应用程序被拒绝打开文件的可能性,否则不要使用此方法。
- attempting to find out what files are open in the legacy application, using the same techniques as ProcessExplorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx (the equivalent of *nix's
lsof
)
- 与独立于操作系统的技术相比,您更容易受到竞争条件的影响
-
Linux/etc.: in addition (or in-lieu) of the OS-independent method above, you may attempt to use the same technique as
lsof
or, on some systems, simply check which file the symbolic link /proc/<pid>/fd/<fdes>
points to
- 与独立于操作系统的技术相比,您更容易受到竞争条件的影响
- 遗留应用程序使用锁定的可能性极小,但如果是的话,锁定不是一个真正的选择,除非遗留应用程序可以优雅地处理锁定的文件(通过阻止,而不是失败 - 并且如果您自己的应用程序可以保证该文件不会保持锁定状态,从而在较长时间内阻止旧应用程序。)
UPDATE 2
如果赞成“检查遗留应用程序是否打开文件”(容易出现竞争条件的侵入方法),那么您可以通过以下方式解决所述竞争条件:
- 检查旧应用程序是否打开了文件(a la
lsof
or ProcessExplorer
)
- 暂停旧的申请流程
- 重复步骤 1 中的检查,以确认旧应用程序在步骤 1 和 2 之间没有打开该文件;如果是则延迟并重新开始步骤1,否则继续步骤4
- 在文件上处理您的业务 - 理想情况下只需将其重命名以进行后续的独立处理,以便使遗留应用程序暂停最短的时间
- 恢复旧的申请流程
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)