Re: [PATCH] hfsplus: preserve FinderInfo when listing extended attributes

[Viacheslav Dubeyko]

On Wed, 2026-10-21 at 13:45 -0400, Hengyu Liang wrote:
> Commit aef507847129 ("hfsplus: fix generic/062 xfstests failure")
> made
> hfsplus_listxattr() return zero when the inode has no records in the
> attributes B-tree.
> 
> However, osx.com.apple.FinderInfo is stored in the catalog record,
> and
> hfsplus_listxattr() has already added it to the result at that point.
> Setting the result to zero drops it. As of now, a file whose only
> extended attribute is FinderInfo gets an empty list on a volume with
> an attributes B-tree, which mkfs.hfsplus creates by default.
> getxattr()
> still returns the value.
> 
> The issue can be reproduced with:
> 
>     truncate -s 64M hfs.img
>     mkfs.hfsplus hfs.img
>     mount -o loop hfs.img /mnt
>     touch /mnt/file
>     v=0x54455854$(printf %056d 0)
>     setfattr -n osx.com.apple.FinderInfo -v $v /mnt/file
>     getfattr -m - /mnt/file
> 
> Without this patch, getfattr prints nothing. With this patch, it
> lists
> the FinderInfo entry.
> 
> This patch keeps the result of hfsplus_listxattr_finder_info() when
> no
> attributes B-tree records are found, as is already done when the
> volume has no attributes B-tree. A file without extended attributes
> still gets an empty list.
> 
> Fixes: aef507847129 ("hfsplus: fix generic/062 xfstests failure")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Hengyu Liang <hengyul@xxxxxxxxxx>
> ---
> Tested in KVM with KASAN on a804c5742bff, without and with this
> patch:
> - The commands above, and a C test of listxattr() sizes and buffer
>   lengths: a file with only FinderInfo gives 0 without the patch and
>   25 with it; a file without extended attributes gives 0 on both.
> - generic/062: 10/10 passed on both kernels.
> - Full fstests (805 generic tests): 186 passed, 11 failed and 608 not
>   run on both kernels, with the same failing tests. fsck.hfsplus -fn
>   reported no new errors.
> 
> With this patch, getfattr above prints "osx.com.apple.FinderInf". The
> last character is lost by a separate bug in copy_name(), which
> Maurycy
> Pawlowski-Wieronski's patch fixes:
> https://lore.kernel.org/all/20260828-hfsplus-copy_name-fix-v1-1-75ed9f0f378c@xxxxxxxxxxx/

Somehow, discussion went nowhere. I am still waiting answers on my
questions. It will be great if you could revive the discussion or to
resend the patch addressing my comments.

> 
>  fs/hfsplus/xattr.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
> index 71364e093fa7..c74c81966f12 100644
> --- a/fs/hfsplus/xattr.c
> +++ b/fs/hfsplus/xattr.c
> @@ -838,7 +838,6 @@ ssize_t hfsplus_listxattr(struct dentry *dentry,
> char *buffer, size_t size)
>  	err = hfsplus_find_attr(inode->i_sb, inode->i_ino, NULL,
> &fd);
>  	if (err) {
>  		if (err == -ENOENT || err == -ENODATA) {
> -			res = 0;
>  			goto end_listxattr;
>  		} else {
>  			res = err;

I think the fix makes sense. Maybe, we need to slightly rework the code
here:

err = hfsplus_find_attr(inode->i_sb, inode->i_ino, NULL, &fd);
if (err) {
    if (err != -ENOENT && err != -ENODATA)
        res = err;
    goto end_listxattr;
}

What do you think?

Thanks,
Slava.

> 
> base-commit: a804c5742bff224d4cb4d25dd383554d598be32b