os.remove后跟os.path.isfile可以不同意吗？ [英] Can os.remove followed by os.path.isfile disagree?
问题描述
在os.remove（x）成功完成后，os.path.isfile（x）能否返回True？ （Windows 2003，Python 2.3）
我们在服务器应用程序中遇到了几个故障，我们还不能在一个简单的情况下重现
。对代码的分析表明
唯一可能的解释是发生以下情况，
os.remove（x）
.....东西
如果os.path.isfile（x）：
加注哎呀，我们怎么到这里来的？
file（x，" wb"）。write（content）
我们最终加薪。当我们看到系统时，
文件实际上已经消失了，大概是因为os.remove。
东西是一些代码行，不需要花费大量时间来执行。没有尝试阻止在os.remove调用中屏蔽
失败。
应用程序是多线程的，因此有可能另一个线程
写入删除之间的文件和isfile，但在
结束时，文件实际上不在文件系统上，而且我不知道有没有办法该场景可以在
中再次移除。
问候，
Paul
Can os.path.isfile(x) ever return True after os.remove(x) has
successfully completed? (Windows 2003, Python 2.3)
We had a couple of failures in a server application that we cannot yet
reproduce in a simple case. Analysis of the code suggests that the
only possible explanation is that the following occurs,
os.remove(x)
..... stuff
if os.path.isfile(x):
raise "Ooops, how did we get here?"
file(x, "wb").write(content)
We end up in the raise. By the time we get to look at the system the
file is actually gone, presumably because of the os.remove.
The "stuff" is a handful of lines of code which don''t take any
significant time to perform. There are no "try" blocks to mask a
failure in the os.remove call.
The application is multithreaded so it is possible that another thread
writes to the file between the "remove" and the "isfile", but at the
end of the failure the file is actually not on the filesystem and I
don''t believe there is a way that the file could be removed again in
this scenario.
Regards,
Paul
推荐答案
pp ******* @ gmail.com 写道：
os.remove（x）之后os.path.isfile（x）能否返回True
顺利完成？ （Windows 2003，Python 2.3）
我们在服务器应用程序中遇到了几个故障，我们还不能在一个简单的情况下重现
。对代码的分析表明
唯一可能的解释是发生以下情况，
os.remove（x）
....
如果os.path.isfile（x）：
加注哎呀，我们怎么到这里来的？
file（x，" wb"）。write（content）
我们最终加薪。当我们看到系统时，
文件实际上已经消失了，大概是因为os.remove。
东西是一些代码行，不需要花费大量时间来执行。没有尝试阻止在os.remove调用中屏蔽
失败。
该应用程序是多线程的，因此可能是另一个线程
在删除之间写入文件。和isfile，但在
结束时，文件实际上不在文件系统上，而且我不知道有没有办法该方案可以在
中再次删除该文件。
Can os.path.isfile(x) ever return True after os.remove(x) has
successfully completed? (Windows 2003, Python 2.3)
We had a couple of failures in a server application that we cannot yet
reproduce in a simple case. Analysis of the code suggests that the
only possible explanation is that the following occurs,
os.remove(x)
.... stuff
if os.path.isfile(x):
raise "Ooops, how did we get here?"
file(x, "wb").write(content)
We end up in the raise. By the time we get to look at the system the
file is actually gone, presumably because of the os.remove.
The "stuff" is a handful of lines of code which don''t take any
significant time to perform. There are no "try" blocks to mask a
failure in the os.remove call.
The application is multithreaded so it is possible that another thread
writes to the file between the "remove" and the "isfile", but at the
end of the failure the file is actually not on the filesystem and I
don''t believe there is a way that the file could be removed again in
this scenario.
os.remove实现（在posixmodule.c中）使用
DeleteFileW / A API调用（取决于Unicode与否）：
http：// msdn2。 microsoft.com/En-US/library/aa363915.aspx
没有暗示它可能在完成之前返回，
但是我'如果它确实会感到惊讶。
最可能的赌注似乎是竞争条件
，如下所示。不一定要在你的程序中使用一个线程
，虽然我假设你最了解
你自己的文件系统;）
另一种可能性 - 我想，虽然没有任何
权限 - 是.remove正在默默吞咽
一个错误（即在没有任何操作系统级别的情况下失败）告诉Python
所以不会引发异常）。更有可能是那个......东西中的某个地方。是b / b
无意中重新创建了文件。
不要以为你有某种华丽的软件
运行哪些拦截OS文件操作调用
病毒或存档目的？
TJG
The os.remove implementation (in posixmodule.c) uses
the DeleteFileW/A API call (depending on Unicode or not):
http://msdn2.microsoft.com/En-US/library/aa363915.aspx
No suggestion there that it might return before completion,
but I''d be surprised if it did.
The most likely bet would seem to be a race condition
as you suggest below. Doesn''t have to be from a thread
in your program, although I assume you know best about
your own filesystem ;)
Another possibility -- I suppose, though without any
authority -- is that the .remove is silently swallowing
an error (ie failing at OS level without telling Python
so no exception is raised). Much more likely is that
somewhere in that "...stuff" is something which
inadvertently recreates the file.
Don''t suppose you''ve got some kind of flashy software
running which intercepts OS file-manipulation calls for
Virus or Archiving purposes?
TJG
pp*******@gmail.com 写道：
os.remove（x）成功完成后，os.path.isfile（x）能否返回True？ （Windows 2003，Python 2.3）
Can os.path.isfile(x) ever return True after os.remove(x) has
successfully completed? (Windows 2003, Python 2.3)
作为事后的想法，您是否尝试过NTFS审计，或者
目录监控，例如：
http://timgolden.me。 uk / python / win32 _... rectorychanges
查看目录中的事件序列？至少
可以确认你是否看到了
delete-create-delete或其他一些模式。
TJG
As an afterthought, have you tried NTFS auditing, or
directory monitoring, such as:
http://timgolden.me.uk/python/win32_...rectorychanges
to see the sequence of events on the directory? At least
that might confirm whether you are seeing
delete-create-delete or some other pattern.
TJG
pp*******@gmail.com 写道：
< SNIP>
pp*******@gmail.com wrote:
<SNIP>
>
该应用程序是多线程的，因此可能是另一个线程
写入删除之间的文件。和isfile，但在
结束时，文件实际上不在文件系统上，而且我不知道有没有办法这个场景可以在
中再次删除。
>
The application is multithreaded so it is possible that another thread
writes to the file between the "remove" and the "isfile", but at the
end of the failure the file is actually not on the filesystem and I
don''t believe there is a way that the file could be removed again in
this scenario.
这听起来像是一个线程竞争条件。理论上，os.remove调用
在返回之前未能实际删除文件也可能会这样做，
但似乎不太可能是一个在基础操作系统中明显的错误即使在Windoze中，电话也可以很长时间存活。
我会花时间真正检查你正在运行的多个工作线程
确保其中一个没有像另一个创建它一样删除文件。
更好的是，在代码周围使用锁定信号量创建/删除文件
以保证相互排斥。
This sure sounds like a thread race condition. In theory, the os.remove call
failing to actually remove the file before returning might also do this,
but it seems unlikely that a bug that blatant in a fundamental OS call could
survive very long, even in Windoze.
I''d take the time to really examine the multiple threads of work you''re running
to make sure one of them isn''t removing the file just as another creates it.
Better still, use a locking semaphore around the code the creates/deletes the file
to guarantee mutual exclusion.
这篇关于os.remove后跟os.path.isfile可以不同意吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
