Hi Hin-Tak,
On Mon, 2014-04-14 at 11:08 +0100, Hin-Tak Leung wrote:
> Those files returns 'no such attribute' when doing getfattr -m ''.
> Their user_info and finder_info are entirely nulls. But that's quite
> expected since those files are not user created and not accessible by
> finder. So they should simply be quiet, rather than resulting in 'no
> such attribute' error.
>
My logic was simple. If we haven't xattrs in AttributesFile and
user_info and finder_info are entirely nulls (nothing show to user) then
it means that we haven't xattrs completely. It is one of the possible
point of view.
>From another point of view, we can think that we have
"com.apple.FinderInfo" xattr always. And we can show array of zero for
the case of empty user_info and finder_info areas. It is possible to
simplify hfsplus_listxattr_finder_info() method:
static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
char *buffer, size_t size)
{
ssize_t res = 0;
struct inode *inode = dentry->d_inode;
struct hfs_find_data fd;
u16 entry_type;
int xattr_name_len, symbols_count;
res = hfs_find_init(HFSPLUS_SB(inode->i_sb)->cat_tree, &fd);
if (res) {
pr_err("can't init xattr find struct\n");
return res;
}
res = hfsplus_find_cat(inode->i_sb, inode->i_ino, &fd);
if (res)
goto end_listxattr_finder_info;
entry_type = hfs_bnode_read_u16(fd.bnode, fd.entryoffset);
if (entry_type != HFSPLUS_FOLDER && entry_type != HFSPLUS_FILE) {
res = -EOPNOTSUPP;
goto end_listxattr_finder_info;
}
symbols_count = sizeof(HFSPLUS_XATTR_FINDER_INFO_NAME) - 1;
xattr_name_len =
name_len(HFSPLUS_XATTR_FINDER_INFO_NAME, symbols_count);
if (!buffer || !size) {
if (can_list(HFSPLUS_XATTR_FINDER_INFO_NAME))
res = xattr_name_len;
} else if (can_list(HFSPLUS_XATTR_FINDER_INFO_NAME)) {
if (size < xattr_name_len)
res = -ERANGE;
else {
res = copy_name(buffer,
HFSPLUS_XATTR_FINDER_INFO_NAME,
symbols_count);
}
}
end_listxattr_finder_info:
hfs_find_exit(&fd);
return res;
}
> In fact there seems to be another related issue: linux created files
> under hfs+ have their finderinfo ( creater and file type, etc) filled
> with garbage. I think there were a bug report a while back about the
> finder flags (also part of finderinfo) being filled with gabbage, but
> those were corrected.
>
I think that this method is not the point of deep check of file system
consistency. This method is checking entry type. I think that such check
is enough here. The hfsplus_find_cat() makes some checking consistency
of b-tree nodes. And if we will have real garbage then trying to find
catalog record fails. I don't think that it needs to make consistency
checking stricter here.
Thanks,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
