在使用 gsutil 上传大量图像后,我遇到了一个奇怪的问题 - 通过 Google Cloud Console 无法查看上传的文件,如果我尝试执行“gsutil ls”,gsutil 本身就会抱怨。我 99% 确定这与在目录名称中使用“å”或“Å”以及空格有关。
所有上传都是从根文件夹递归完成的(多级子目录中的大型图像集合)。如果我尝试再次上传文件,gsutil 会跳过它们,因为它们已经存在,所以上传功能会做一些事情- 它与列表和下载的工作方式不同。
一个例子:
gsutil cp -R -n /Volumes/Photos/digitalfotografen.dk/2009/2009-05-30\ Søgården\ -\ bryllup/ gs://digitalfotografen/2009/
Skipping existing item: gs://digitalfotografen/2009/2009-05-30 Søgården - bryllup/Søgården 0128.CR2
...
好的 - 文件在那里,但通过 Google Cloud Console 浏览目录显示“无结果”。
还:
gsutil ls gs://digitalfotografen/2009/2009-06-27 Søgården - reklamefotos/20090627_IMG_0128.CR2
CommandException: "ls" command does not support "file://" URIs. Did you mean to use a gs:// URI?
我尝试转义空格并以不同的方式使用引号,但没有成功。
现在,有趣的是:
gsutil cp -R -n /Volumes/Photos/digitalfotografen.dk/2009/2009-05-30\ Søgården\ -\ bryllup/ gs://digitalfotografen/2009/
Copying file:///Volumes/Photos/digitalfotografen.dk/2009/2009-05-30 Søgården - bryllup/Søgården 0128.CR2 [Content-Type=application/octet-stream]...
这里我在源端专门复制了带有转义空格的文件夹,现在文件再次上传。这将创建另一个同名文件夹(至少在 Cloud Console 中如此显示),并且文件现在在两个文件夹中都可见。
我们在丹麦字符集中使用了标准美国 ASCII 之外的三个不同字符(“æøå”和大写“ÆØÅ”),但问题似乎只影响“å”和“Å”——另外两个单独或组合工作正常。我的预感是“å”和“Å”可能会在 ASCII 中翻译成完全不同的东西,当允许 gsutil 根据根文件夹的名称自行处理目录命名时(进行多级递归),这会使事情偏离轨道) 但在用户指定根文件夹的转义名称时有效。
这可能是 python 问题而不是 gsutil 问题,但我没有资格确定这一点,因为我对一些大杂烩 shell 脚本之外的编程知识几乎为零。