为什么 s3cmd du 根据路径末尾的斜杠给出不同的结果？

Question

s3cmd du -H s3://bucketabc/prefix/further-prefix

给21G

s3cmd du -H s3://bucketabc/prefix/further-prefix/

提供 10G。

里面没有直接的文件，只有四个“子目录”。

我有五个近似副本的存储桶，这只发生在其中两个中。其他的一直显示 10G。

存储桶和看似无关的存储桶之间唯一明显的区别是，带或不带斜线的两个提供 10G 的子目录比其他的有一个 more 子目录，只有一个 138M文件。

为什么是 21G 与 10G？哪个是正确的答案？

Answer 1

在 S3 REST API 中，当迭代对象时，您通常会指定一个键前缀，它是一个左锚子字符串，匹配您想要返回的所有键值。

当您告诉 S3 您想要 foo/ 时，您所要求的当然是 foo/*。

也许不太直观的是，请求foo 确实是在请求foo*，其中包括foo*/*。

这是一个 前缀 匹配。任何具有匹配前缀的键都将被包括在内，因此前缀foo 不仅包括foo/*，还包括foobar/* 等。

这就是为什么我们中的一些人似乎如此喜欢发出“S3 不是文件系统，它是一个对象存储”的友好提醒，即使在某种程度上，您已经知道这一点。它不完全遵循文件系统语义。我认为，这就是有时看似微妙的区别很重要的原因之一。

与文件系统不同，S3 中的目录层次结构并不真正存在。这是基于/ 字符的方便错觉。您可以在控制台中创建的文件夹同样是一种错觉——它们是控制台允许您添加的空对象，以便在您在存储桶中实际拥有任何具有该前缀的键之前创建层次结构的外观。因此，没有对象实际上是“在”文件夹中的概念，它们只是“在”文件夹中。

如果没有尾部斜线，我怀疑由于前缀匹配范式，您匹配的次数比预期的要多。