2

我正在使用 Python 2.7.6 从 Windows Server 2008 R2 上的 Windows CMD 脚本运行 GSUTIL v3.42。要上传的文件到达“传出”目录，并由 GSUTIL 并行上传到“传入”存储桶。该脚本在上传完成后请求“传入”存储桶的列表，然后将列出的文件与其尝试上传的文件进行比较，以检测任何上传失败。另一个单独的脚本随后将文件从“传入”存储桶移动到“已处理”存储桶。

如果我尝试再次上传相同的文件（相同的名称/大小/内容/日期等），它不会上传，尽管我没有收到任何错误，并且我的日志记录中没有任何内容表明失败。我没有使用“no clobber”选项，所以我希望 gsutil 只上传文件。

在下面的场景中，假设文件已成功上传并在当天已移动到“已处理”存储桶中。如果时间很重要，第二次上传将在第一次上传的半小时内尝试。

  1. 文件 A 到达“传出”目录。
  2. 我得到“传出”的文件列表并将其写入 dirListing.txt

  3. 我使用执行 GSUTIL 上传

    类型 dirListing.txt | python gsutil -m cp -I -L myGsutilLogFile.txt gs://myIncomingBucket

  4. 然后我执行 GSUTIL 列表

    python gsutil ls -l -h gs://myIncomingBucket > bucketListing.txt

  5. 文件匹配 dirListing.txt 和 bucketListing.txt 以检测不匹配并因此上传失败。

在第二次运行中，文件 A 在步骤 3 中没有被上传，因此在步骤 4 中没有返回，导致在步骤 5 中不匹配。[我检查了所有相关文件的内容，它肯定在 dirListing .txt 而不是 bucketListing.txt]

我需要重新处理文件的能力，以防将文件从“传入”存储桶移动到“已处理”存储桶的单独脚本由于某种原因失败或没有做它应该做的事情。我必须并行上传，因为每次运行通常有数百个文件。

我在上面描述的是 GSUTIL 的预期行为吗？（我在文档中没有看到任何暗示这一点的内容）如果是这样，有没有办法强制 GSUTIL 重新尝试上传？还是我遗漏了一些明显的东西？如果有必要/有用，我有来自 GSUTIL 的调试输出。

4

1 回答 1

3

从上面看，您似乎正在使用“-L”上传以登录到清单文件。如果您使用的是同一个清单文件，并且该文件已经上传过一次，那么 gsutil 将不会尝试重新上传该文件。来自“gsutil help cp”中“-L”的文档：

如果日志文件已经存在，gsutil 将使用该文件作为复制过程的输入，并将日志项附加到现有文件中。在现有日志文件中标记为已成功复制（或跳过）的文件/对象将被忽略。

于 2014-02-26T18:01:42.263 回答