sysopen 权限被拒绝

发布于 2024-09-25 17:45:00 字数 1371 浏览 5 评论 0原文

我正在尝试修复 git-svn。该问题仅发生在 Windows XP 中，同时使用 Cygwin git (perl v5.10.1) 和 msysGit (perl v5.8.8)。

对于任何涉及获取的操作，我都可以完成一半，然后操作就会终止，并显示类似于以下内容的消息

无法打开 .git/svn/refs/remotes/trunk/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock：设备或资源繁忙
位于 /usr/lib/git-core/git-svn 第 5240 行

繁忙但是，确切的锁定文件和行号并不总是相同。我已将实际问题跟踪到第 3679 行

sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)

This is 创建一个新的 .lock 文件，我尝试了等效的方法但无济于事。

open(my $fh, ">", $db_lock)

我检查了该目录的权限，是drwxr-xr-x，所以应该不会有问题，或者如果有的话也不会这么不一致。

这是否是因为脚本快速连续多次创建和重命名该文件，导致 XP 无法处理它？编辑：我怀疑情况确实如此，因为当我使用 perl 调试器并手动启动每个 sysopen 的执行时，我获取的 100 个修订版没有问题。

编辑：一些 Git 开发人员更愿意找出根本原因，而不是采用恰好有效的 hack（我认为这是正确的方法）。那么，任何人都可以帮我找到拒绝我打开这些 .lock 文件的权限的罪魁祸首吗？我有很多理论上可以用于此目的的工具，但它们并不能完全发挥作用：

Process Explorer - 显示进程拥有的所有句柄，并且还可以搜索拥有给定句柄的所有进程。但是，它对于短期进程或句柄（这就是 git svn clone/fetch 所做的）效果不佳。
Unlocker - 检测何时出现通用“权限被拒绝”对话框，并找到有问题的句柄并提供处理他们。但是，当非资源管理器程序遇到基于文件的错误时，它不会出现。

简而言之，有什么方法可以让我在不成为 Microsoft 员工的情况下获得更多信息吗？

编辑2：这可能不是赛门铁克，而是我们在联网计算机上运行的另一个程序。我有人在调查这个问题，他们至少应该能够缩小问题的范围。

原文

I'm trying to fix an intermittent bug in git-svn. The problem is happening in Windows XP only, with both Cygwin git (perl v5.10.1) and msysGit (perl v5.8.8).

With any operation that involves a fetch, I'm able to get partway through and then the operation dies with a message similar to

Couldn't open .git/svn/refs/remotes/trunk/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy
at /usr/lib/git-core/git-svn line 5240

However, the exact lock file and line number are not always the same. I've tracked the actual problem to line 3679

sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)

This is creating a new .lock file, and I tried the equivalent to no avail.

open(my $fh, ">", $db_lock)

I checked the permissions of the directory, and it is drwxr-xr-x, so there shouldn't be any problems, or if they were, they wouldn't be so inconsistent.

Could this be because the script is creating and renaming this file so many times in quick succession that XP can't handle it? EDIT: my suspicion is that this is the case, because when I used the perl debugger and kicked off the execution of each sysopen manually, there were no problems for the 100 revisions I fetched.

EDIT: Some Git developers would much rather find out the root cause than go with a hack that happens to work (the right approach, I think). So, can anyone help me find the culprit denying my permission to open these .lock files? I have a number of tools that could theoretically be used for this purpose, but they don't quite go all the way:

Process Explorer - shows all handles owned by a process, and can also search for all processes owning a given handle. However, it doesn't work well for short lived processes or handles (which is what git svn clone/fetch do)
Unlocker - Detects when a generic 'permission denied' dialog appears and finds the offending handle(s) and offers to deal with them. However, it doesn't come up when non-explorer programs encounter file-based errors

In short, is there any way I can get more information without being a Microsoft employee?

EDIT 2: It's probably not Symantec, but another program we have running on the networked computers. I have some people looking into it, and they should be able to at least narrow down the cause here.

分享到QQ

分享到微博

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

发布评论

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

土豪 2024-10-02 17:45:01

此类行为通常可归因于防病毒组件使文件保持打开状态并延迟删除。

回复收藏 0 原文

烟燃烟灭 2024-10-02 17:45:01

我目前的解决方案是用这个替换 sysopen

my $fh;
if ($^O eq 'MSWin32' or $^O eq 'cygwin') {
   for my $try (1..10) { # Retry up to 10 times on problematic systems
       sysopen($fh, $db_lock, O_RDWR | O_CREAT);
       last if $fh;
   }
} else {
   sysopen($fh, $db_lock, O_RDWR | O_CREAT);
}

croak "Couldnt open $db_lock: $!\n" unless $fh;'

到目前为止，它运行得很好。大多数时候它不会打印任何 . ，偶尔会打印一个 . ，而且我还没有看到它连续打印多个 . 。这个解决方案是不是太hacky了？

编辑：我的代码被 Ævar Arnfjörð Bjarmason 的清理版本替换。

My current hack of a solution is to replace the sysopen with this

my $fh;
if ($^O eq 'MSWin32' or $^O eq 'cygwin') {
   for my $try (1..10) { # Retry up to 10 times on problematic systems
       sysopen($fh, $db_lock, O_RDWR | O_CREAT);
       last if $fh;
   }
} else {
   sysopen($fh, $db_lock, O_RDWR | O_CREAT);
}

croak "Couldnt open $db_lock: $!\n" unless $fh;'

And so far, it's working pretty well. Most of the time it doesn't print any .'s, and occasionally it prints one, and I haven't seen it print more than one in a row. Is this solution too hacky?

Edit: My code replaced by Ævar Arnfjörð Bjarmason's cleaned up version.

回复收藏 0 原文