☰

为什么 tar 标志 --strip-components 有时会被忽略？

tag-icon • tag-icon tar
为什么 tar 标志 --strip-components 有时会被忽略？

我有一个自动的 docker 镜像构建，我可以在其中下载 elasticsearch 存档并通过以下方式提取它：

tar zxf archive.tar.gz --strip-components=1 -C /path/to/dir

直到最新版本（6.8.5 和 7.4.2）发布之前，它一直有效。它不再适用于 6.8.5，这意味着该标志--strip-components不再有效。但是，它适用于 7.4.2。比较这两个档案后，我发现的唯一区别是 6.8.5 对档案中的文件拥有不同的所有权 -与 7.4.2631:503不同root:root。但是，如果那是问题标志--no-same-owner或--user应该解决问题，他们没有。我甚至用这些 ID 创建了一个用户/组，并提取了该用户下的档案，但它也没有效果。

您可以这样重现此问题（将 6.8.5 替换为 7.4.2 以尝试两者）：

$ docker run --rm -ti alpine:3.10.3 sh

### from the container

$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.8.5.tar.gz
$ apk add --update tar
$ mkdir elastic
$ tar zxvf elasticsearch-6.8.5.tar.gz --strip-components=1 -C elastic
$ ls -la elastic

使用 6.8.5 时，您将看到未被剥离的中间目录；使用 7.4.2 时，您将看不到它，尽管它存在于两个档案中。

您可能注意到，我没有使用tarmusl，而是使用了 alpine 软件包（版本 1.32）中的 GNU 版本，该版本已经存在几个月了。我在许多其他版本中使用此软件包和相同的标志，它对我来说工作得很好。

答案1

就像解释github 上的 Elastic 工作人员告诉我，这种情况的发生是由于./档案库中的路径存在引导：

/ # tar tvf elasticsearch-6.8.5.tar.gz --numeric-owner | head -n 2
drwxr-xr-x 631/503           0 2019-11-14 14:20 ./
drwxr-xr-x 631/503           0 2019-11-13 20:07 ./elasticsearch-6.8.5/

因此，在这种情况下--strip-components应该是 2，而不是 1。为了普遍处理这种情况，您可以在提取之前列出档案，如果有，./您可以动态更改--strip-components计数：

$ if tar tf elasticsearch-6.8.5.tar.gz | head -n 1 | grep -q '^./$'; then STRIP_COMPONENTS_COUNT=2; else STRIP_COMPONENTS_COUNT=1; fi
$ tar zxvf elasticsearch-6.8.5.tar.gz --strip-components=$STRIP_COMPONENTS_COUNT -C elastic

但是，老实说，好的档案不应该被创建，因为./这会非常令人困惑，因为除非您列出档案中的文件，否则您不会注意到任何差异。

相关内容