[PATCH] erofs-utils: tar: support archives without end-of-archive entry

[Gao Xiang]

Hi Ivan,

On Mon, Sep 29, 2025 at 04:32:22PM +0300, Ivan Mikheykin wrote:
> Tar standard https://www.gnu.org/software/tar/manual/html_node/Standard.html
> says that archive "terminated by an end-of-archive entry,
> which consists of two 512 blocks of zero bytes".
> 
> Is also says:
> 
> "A reasonable system should write such end-of-file marker at the end
> of an archive, but must not assume that such a block exists when
> reading an archive. In particular, GNU tar does not treat missing
> end-of-file marker as an error and silently ignores the fact."
> 
> It is rare for erofs to encounter such problem, as images are mostly
> built with docker or buildah. But if you create image using tar library
> in Golang directly uploading layers to registry, you'll get tar layers
> without end-of-archive block. Running containers with such images will
> trigger this error during extraction:
> 
> mkfs.erofs --tar=f --aufs --quiet -Enoinline_data test.erofs test-no-end.tar
> <E> erofs: failed to read header block @ 42496
> <E> erofs: 	Could not format the device : [Error 5] Input/output error
> 
> This patch fixes the problem by assuming that eof is equal to the end-of-archive.
> 
> Reproducible tar without end-of-archive (base64-encoded gzipped blob):
> H4sICKVi2mgAA3Rlc3QtMTAtMi1ibG9ja3MudGFyAAtzDQr29PdjoCUwAAIzExMwbW5mCqYN
> jQzANBgYGTEYmhqYmpqamRoaGTMYGBqaGJkyKBjQ1FVQUFpcklikoMCQkpmYll9ahFNdYkpu
> Zh49HERfYKhnoWdowGVkYGSqa2Cua2jKNdAuGgX0BADwFwqsAAQAAA==

Thanks for the patch!

Could you confirm how docker/containerd or podman parses such image?

Because the POSIX standard says:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
"At the end of the archive file there shall be two 512-byte blocks filled
with binary zeros, interpreted as an end-of-archive indicator."

So such tar layers will be non-standard, I wonder we need at least
a erofs_warn() message for such tars at least.

Thanks,
Gao Xiang

> 
> Signed-off-by: Ivan Mikheykin <ivan.mikheykin at flant.com>