GSUTIL不会重新上传当天早些时候已上传的文件

Question

我正在使用Python 2.7.6从Windows服务器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＆gt; bucketListing.txt

5. 文件匹配dirListing.txt和bucketListing.txt以检测不匹配，从而导致上传失败。

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

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

我上面描述的是GSUTIL的预期行为吗？ （我没有在文档中看到任何暗示这一点的内容）如果是这样，有没有办法迫使GSUTIL重新尝试上传？或者我错过了一些明显的东西，拜托？我有GSUTIL的调试输出，如果这是必要/有用的。

Answer 1

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

  

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