gsutil上的ResumableUploadAbortException

Question

在使用gsutil时，我一直看到以下错误

ResumableUploadAbortException: Upload complete with 6275 additional bytes left in stream

这个命令非常简单，类似于

gsutil cp -r <source_path> gs://<target-bucket>/<target_path>

在<source_path>中有大约80个文件。<source_path>内部也有嵌套文件夹。将gsutil cp更改为gsutil -m cp没有什么区别。当我在python脚本和许多其他代码中运行它时，这个错误是可重复的。但是，当我在bash中单独运行命令时，它似乎没有任何问题。所以我想知道ResumableUploadAbortException的原因是什么，好吗？

使用gsutil -D -m cp调试输出的尾

total_bytes_transferred: 794750002
Total bytes copied=794750002, total elapsed time=7.932 secs (95.55 MiBps)
DEBUG: Exception stack trace:
    Traceback (most recent call last):
      File "/usr/lib/google-cloud-sdk/platform/gsutil/gslib/__main__.py", line 565, in _RunNamedCommandAndHandleExceptions
        parallel_operations, perf_trace_token=perf_trace_token)
      File "/usr/lib/google-cloud-sdk/platform/gsutil/gslib/command_runner.py", line 280, in RunNamedCommand
        return_code = command_inst.RunCommand()
      File "/usr/lib/google-cloud-sdk/platform/gsutil/gslib/commands/cp.py", line 998, in RunCommand
        self.op_failure_count, plural_str, plural_str))
    CommandException: CommandException: 1 file/object could not be transferred.

Answer 1

确保您正在传输在传输过程中更改的文件。在我的例子中，问题是我将输出重定向到一个日志文件，而日志文件也被传输到云端，这导致了上面的问题。

Answer 2

使用WSL2？

WSL有一个众所周知的问题，它会导致时间不同步。

在我的例子中，时间不同步似乎导致了ResumableUploadAbortException。

要修复它，只需同步WSL 2：sudo nohup watch -n 10 ntpdate time.windows.com > /dev/null 2>&1 &中的时间即可。

Answer 3

gsutil命令建议“删除跟踪器文件”以解决问题。这确实解决了我的问题：

rm -rf ~/.gsutil/tracker-files