偶尔的OSError：[Errno 13] Windows上的权限被拒绝 [英] Occasional OSError: [Errno 13] Permission denied on Windows
问题描述
在Windows XP上使用Python 2.3.5，我偶尔会遇到OSError：[Errno
13]调用os.remove（）时权限被拒绝。这可能发生在机器上任何其他进程未使用的
文件中，并且是由试图删除它的python.exe调用创建的
。它可以在我的系统的各个部分发生
- 几乎我尝试的任何地方
删除文件。
我假设问题是我正在抓住我试图删除的文件的句柄。我搜索了我的代码并关闭了
我能找到的文件的任何句柄。
的间歇性这个问题让我相信我并没有明确地把某个
文件对象放在某个地方。
我的下一个理论是，有一些对象持有一个文件
句柄，其中没有现存的参考，但是没有
垃圾回收。所以，我尝试删除这样的文件：
尝试：
os.remove（strPath）
除了OSError：
＃狂野猜测垃圾收集可能会清除错误13
gc.collect（）
os.remove（strPath）
这确实减少了问题的发生频率，但它并没有让b b $ b完全消失。我真的需要解决这个问题，因为
我正在开发一个如果它无法删除它的
文件就无法生存的应用程序。
谢谢，
Alec Wysoker
Using Python 2.3.5 on Windows XP, I occasionally get OSError: [Errno
13] Permission denied when calling os.remove(). This can occur with a
file that is not used by any other process on the machine, and is
created by the python.exe invocation that is trying to delete it. It
can happen with various pieces of my system - almost anywhere I try to
delete a file.
I have assumed that the problem is that I was holding on to a handle to
the file that I was trying to remove. I have scoured my code and close
any handle to the file that I can find. The intermittent nature of
this problem leads me to believe that I''m not explicitly holding onto a
file object somewhere.
My next theory was that there was some object holding onto a file
handle for which there wasn''t an extant reference, but which hadn''t
been garbage-collected. So, I tried removing files like this:
try:
os.remove(strPath)
except OSError:
# Wild guess that garbage collection might clear errno 13
gc.collect()
os.remove(strPath)
This does indeed reduce the frequency of the problem, but it doesn''t
make it go away completely. I really need to fix this problem, because
I''m developing an app that won''t survive if it fails to delete its
files.
Thanks,
Alec Wysoker
推荐答案
Alec Wysoker写道：
Alec Wysoker wrote:
在Windows XP上使用Python 2.3.5，我偶尔会遇到OSError：
[Errno 13]调用os.remove（）时权限被拒绝。这可能发生在
机器上任何其他进程未使用的文件上，并且是由尝试删除它的python.exe调用创建的。它可能发生在我的
系统的各个部分 - 几乎我试图删除文件的任何地方。
Using Python 2.3.5 on Windows XP, I occasionally get OSError:
[Errno 13] Permission denied when calling os.remove(). This can
occur with a file that is not used by any other process on the
machine, and is created by the python.exe invocation that is
trying to delete it. It can happen with various pieces of my
system - almost anywhere I try to delete a file.
我以前工作过的公司实时病毒扫描程序
会导致这样的问题。开车送我坚果，因为我从来没有能够让他们关掉这件事。
问候，
Pat
[Alec Wysoker]
[Alec Wysoker]
在Windows XP上使用Python 2.3.5，我偶尔会遇到OSError：[Errno
13]调用os.remove（）时权限被拒绝。这可能发生在机器上任何其他进程都没有使用的
文件中，
你怎么知道这个？
并且是由试图删除它的python.exe调用创建。它可能发生在我的系统的各个部分 - 几乎我试图删除文件的任何地方。
我认为问题是我抓住了一个句柄
我试图删除的文件。我已经搜索了我的代码并关闭了我能找到的文件的任何句柄。这个问题的间歇性使我相信我没有明确地把某个
文件对象放在某个地方。
我的下一个理论是有一些对象持有到一个文件
句柄，其中没有现存的参考，但没有被垃圾收集。所以，我尝试删除这样的文件：
尝试：
os.remove（strPath）
除了OSError：
#Will猜测垃圾收集可能会清除错误13
gc.collect（）
os.remove（strPath）
这确实减少了问题的频率，但它并没有让它成为现实完全离开。
Using Python 2.3.5 on Windows XP, I occasionally get OSError: [Errno
13] Permission denied when calling os.remove(). This can occur with a
file that is not used by any other process on the machine,
How do you know that?
and is created by the python.exe invocation that is trying to delete it. It
can happen with various pieces of my system - almost anywhere I try to
delete a file.
I have assumed that the problem is that I was holding on to a handle to
the file that I was trying to remove. I have scoured my code and close
any handle to the file that I can find. The intermittent nature of
this problem leads me to believe that I''m not explicitly holding onto a
file object somewhere.
My next theory was that there was some object holding onto a file
handle for which there wasn''t an extant reference, but which hadn''t
been garbage-collected. So, I tried removing files like this:
try:
os.remove(strPath)
except OSError:
# Wild guess that garbage collection might clear errno 13
gc.collect()
os.remove(strPath)
This does indeed reduce the frequency of the problem, but it doesn''t
make it go away completely.
用短暂的睡眠代替gc.collect（）（比如，time.sleep（0.2）），
和看看这是否同样可以减少问题的频率。我的赌注是它会。
最好的猜测是你还没有想到的一些过程_is_
打开文件。例如，如果安装了Copernic桌面搜索并且其快速索引新的和修改的
文件，那么您所看到的内容很常见。选项已启用。其他搜索/索引应用程序，
"文件删除恢复"服务，甚至一些病毒扫描仪都可以产生类似的效果。这就是为什么我在开始时问你怎么_know_
没有其他进程打开文件。你描述的symtoms
与一些后台级实用程序app / service一致简单
为了自己的目的打开文件。
在这种情况下，任何烧掉一些时间并再次尝试的东西都可以更好地工作。用time.sleep（）替换gc.collect（）是一种简单的方法来测试这个假设。因为gc.collect（）做了所有代的
集合，它可以消耗可测量的时间。
Replace gc.collect() there with a short sleep (say, time.sleep(0.2)),
and see whether that does just as well at reducing the frequency of
the problem. My bet is that it will.
Best guess is that some process you haven''t thought about yet _is_
opening the file. For example, what you''re seeing is common if
Copernic Desktop Search is installed and its "Index new and modified
files on the fly" option is enabled. Other searching/indexing apps,
"file deletion recovery" services, and even some virus scanners can
have similar effects. That''s why I asked at the start how you _know_
no other process is opening the file. The symtoms you describe are
consistent with some background-level utility app/service briefly
opening files for its own purposes.
In that case, anything that burns some time and tries again will work
better. Replacing gc.collect() with time.sleep() is an easy way to
test that hypothesis; because gc.collect() does an all-generations
collection, it can consume measurable time.
有趣的理论。我有一个病毒扫描程序，还有谷歌桌面
搜索。有时我在运行一大套单元
测试时会遇到此错误。每个单元测试都是通过清理测试输出
目录开始的，如果不能这样做则失败。我会看到很多（数百？）
测试失败，因为文件无法删除，最后
文件将被删除。我的感觉是，如果病毒扫描程序或桌面搜索保持文件打开状态，那么它只会短暂地执行此操作
。另一方面，当我正在进行单元测试时，我正在嚼着很多CPU，所以在这些情况下可能需要更长的时间。
如果我们假设这个理论是正确的，那么解决方案是什么？
睡了一会儿再试一次？
Interesting theory. I do have a virus scanner, and also Google Desktop
Search. Sometimes I get this error when running a large suite of unit
tests. Each unit test starts off by cleaning the test output
directory, and failing if it can''t do so. I will see many (hundreds?)
tests fail because the file can''t be removed, and then eventually the
file will get removed. My feeling is that if a virus scanner or
desktop search were keeping the file open, that it would only do so
briefly. On the other hand, when I''m running unit tests I''m chewing up
a lot of CPU so perhaps it takes longer in those cases.
If we assume that this theory is correct, then what is the solution?
Sleep for a little while and try again?
这篇关于偶尔的OSError：[Errno 13] Windows上的权限被拒绝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
