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

我使用Python2.7.6在WindowsServer2008R2上从WindowsCMD脚本运行GSUTILV3.42。要上载的文件到达“传出”目录，并由GSUTIL并行上载到“传入”存储桶。脚本在上传完成后请求“传入”存储桶的列表，然后将列出的文件与它试图上传的文件进行比较，以便检测任何上传失败。另一个单独的脚本将文件从“传入”存储桶移动到“已处理”存储桶

如果我试图第二次上传相同的文件（相同的名称/大小/内容/日期等），它不会上传，尽管我没有收到任何错误，在我的日志中也没有任何失败的迹象。我没有使用“no clobber”选项，所以我希望gsutil只上传文件

在下面的场景中，假设文件已成功上载并在当天已移动到“已处理”存储桶。如果时间有问题，第二次上传将在第一次上传的半小时内进行

文件A到达“传出”目录

我得到一个“outgoing”的文件列表，并将其写入dirListing.txt

我使用
执行GSUTIL上传

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

然后执行一个GSUTIL清单

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

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

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

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

---

我上面描述的是GSUTIL的预期行为吗？（我在文档中没有看到任何提示）如果是这样，有没有办法强迫GSUTIL重新尝试上传？还是我遗漏了一些明显的东西？如果有必要/有用的话，我已经从GSUTIL获得了调试输出。

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

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

---

非常感谢你的回答——我昨晚很晚才得出同样的结论，现在觉得自己有点傻了！