gpt4 book ai didi

perl - gsutil cp : concurrent execution leads to local file corruption

转载 作者:行者123 更新时间:2023-12-05 00:54:51 24 4
gpt4 key购买 nike

我有一个 Perl 脚本,它调用“gsutil cp”将 GCS 中的选定内容复制到本地文件夹:

$cmd = "[bin-path]/gsutil cp -n gs://[gcs-file-path] [local-folder]";
$output = `$cmd 2>&1`;

该脚本通过 HTTP 调用,因此可以多次启动(例如,通过双击链接)。发生这种情况时,本地文件最终可能正好是正确大小的两倍,因此显然已损坏。三件事看起来很奇怪:

  1. gsutil 在写入时似乎没有锁定本地文件它,允许另一个线程(在本例中是 gsutil 的另一个实例)写入同一个文件。

  2. '-n' 似乎没有效果。我本来希望它能防止尝试复制操作时 gsutil 的第二个实例。

  3. MD5 签名检查失败:通常 gsutil 会删除如果存在签名不匹配的目标文件,但这显然是并非总是如此。

相关文件大于 2MB(通常约为 5MB),因此可能与自动恢复功能有一些交互。如果本地文件尚不存在,Perl 脚本仅调用 gsutil,但这不会捕获双击(因为 GCS 传输身份验证的时间滞后)。

gsutil 版本:FreeBSD 8.2 上的 3.42

有人遇到过类似的问题吗?任何人有任何见解?

爱德华·李

最佳答案

1) 你是对的,我没有看到源代码中的锁。

2) 这可能是由竞争条件引起的 - 进程 1 检查,发现文件不存在。进程 2 检查,发现文件不存在。进程 1 开始上传。进程 2 开始上传。文档说这是实际上传过程之前的 HEAD 操作——这对于实际上传不是原子的。

3) 对此没有输入。

您可以通过在启动传输之前让您的脚本在文件上保持某种原子锁来解决这个问题 - 即您的检查将遵循以下几行:

use Lock::File qw(lockfile);

if (my $lock = lockfile("$localfile.lock", { blocking => 0 } )) {
... perform transfer ...
undef $lock;
}
else {
die "Unable to retrieve $localfile, file is locked";
}

关于perl - gsutil cp : concurrent execution leads to local file corruption,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23681911/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com