gsutil 上的 ResumableUploadAbortException答案

【问题标题】：ResumableUploadAbortException on gsutilgsutil 上的 ResumableUploadAbortException
【发布时间】：2016-11-01 09:44:47
【问题描述】：

我在使用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.

【问题讨论】：

您使用的是什么版本的 gsutil？
@TravisHobrla, gsutil version: 4.19
您无法在 bash 中重现这一点，这使得您的 python 脚本中的某些内容很可能仍在写入其中一个文件，或者在您调用 @ 之前该文件可能尚未刷新987654331@。你是如何从 Python 调用 gsutil 的？您可以收集gsutil -D cp 日志以查看 gsutil 最初尝试发送的字节范围是否与您预期的文件大小相匹配。
调试输出相当冗长，我应该看什么？我用调试日志的最后一条更新了我的问题。我还将我的代码缩减为仅gsutil 的一部分，并且问题仍然可以重现。虽然我认为不太可能，但如果是冲洗问题，是否意味着我需要使用sys.stdout.flush之类的东西？
您的 Python 代码是否生成了将要传输的文件？如果是这样，您需要确保它们在gsutil 或任何其他实用程序可以安全地复制它们之前都已完全刷新/关闭。至于调试日志，通常您要查找的是在 PUT /resumable/upload/storage 请求之后的 HTTP 标头，例如 content-range: bytes 0-999/1000。该标头中的大小应与源文件中的预期大小相匹配。

标签： google-cloud-storage gsutil

【解决方案1】：

确保您正在传输的文件在传输过程中发生更改。就我而言，问题是我将输出重定向到日志文件，而日志文件也正在传输到云端，从而导致上述问题。

【讨论】：

【解决方案2】：

使用 WSL2？

WSL 有一个 well known issue 导致时间不同步。

就我而言，时间不同步似乎导致了ResumableUploadAbortException。

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

【讨论】：

【解决方案3】：

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

rm -rf ~/.gsutil/tracker-files

【讨论】：