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 <[email protected]>
