Re: [PATCH] erofs-utils: lib: follow symlinks on intermediate tar path components

[Gao Xiang <xiang@kernel.org>]

Hi Mikhail,

On Sat, Jul 25, 2026 at 03:09:20PM +0000, mike.malyshev@gmail.com wrote:
> From: Mikhail Malyshev <mike.malyshev@gmail.com>
> 
> mkfs.erofs --tar fails to convert layers that store files underneath a
> symlinked directory, a very common "usr-merge" layout in RHEL/UBI/Fedora
> based OCI images.  For example a base layer contains
> 
>     lib64 -> usr/lib64        (symlink)
>     usr/lib64/                (directory)
>     lib64/libc.so.6           (regular file, path goes THROUGH the symlink)
> 
> erofs_rebuild_get_dentry() walks the path component by component and, when
> it hits the "lib64" component, finds an existing dentry that is a symlink
> rather than a directory.  Since there are still components left to resolve
> it bails out with -ENOTDIR.  In practice this surfaces as a bogus ~2 TiB
> image and "Could not format the device", making the whole layer
> unconvertible even though nothing is wrong with the tar.
> 
> A real filesystem (and containerd's walking differ, which applies the same
> layers via fs.RootPath) resolves such a path by following the symlink to
> its target directory.  Do the same during tar rebuild: when an intermediate
> path component resolves to a symlink, follow it to the target directory
> (relative targets from the containing directory, absolute targets from the
> tree root), chasing chained symlinks up to a bounded depth to avoid loops.
> 
> Signed-off-by: Mikhail Malyshev <mike.malyshev@gmail.com>

Thanks for the patch and sorry for late reply.

Yes, I assume containerd will resolve the directories like this, but as
a quick reference, could you give some pointer how `tar` utility works
and `posix` documents this behavior?

I plan to release erofs-utils 1.9.3 without this patch soon, and it can
be addressed in erofs-utils 1.9.4 version.

Thanks,
Gao Xiang