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.
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.
------------------------------
On Mon, Apr 14, 2014 10:50 AM BST Vyacheslav Dubeyko wrote:
>Hi Hin-Tak,
>
>On Mon, 2014-04-14 at 10:01 +0100, Hin-Tak Leung wrote:
>> Hi Vyacheslav,
>>
>> I have a few files which don't seem to have valid finderinfo data:
>>
>> /mnt/.Spotlight-V100/.journalHistoryLog
>> /mnt/.Spotlight-V100/.store.db
>> /mnt/.Spotlight-V100/_rules.plist
>> /mnt/.Spotlight-V100/ContentIndex.db
>> /mnt/.Spotlight-V100/store.db
>>
>> But since they are spotlight files, and the spotlight directory is special
>> (it is filtered from fsevent in xnu). Also they don't have meaningful
>> finderinfo anyway, since they aren't created by user nor used by any applications.
>>
>> The failure is near
>> "if (found_bit >= (len*8)) res = 0;" in attr.c -
>>
>
>Sorry, I don't quite follow your description. What is the essence of the
>issue? What reproducing path of the issue?
>
>Sorry, but I misunderstand completely the description of the issue. It's
>really hard to answer something without understanding of the issue's
>environment. Could you describe how you've achieved the issue?
>
>Thanks,
>Vyacheslav Dubeyko.
>
>> I am thinking of just doing this, to accept entirely empty ones:
>>
>> diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
>> index 6c0aef0..941a4aa 100644
>> --- a/fs/hfsplus/xattr.c
>> +++ b/fs/hfsplus/xattr.c
>> @@ -777,7 +777,6 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size)
>> if (err) {
>> if (err == -ENOENT) {
>> if (res == 0)
>> - res = -ENODATA;
>> goto end_listxattr;
>> } else {
>> res = err;
>>
>>
>> I am not sure why you have the "if (found_bit >= (len*8))" check - although not
>> having any meaningful finderinfo is strange, but a fair number of files/directories
>> are special and/or invisible to finder, so it is legitimate not to have them?
>>
>> Hin-Tak
>> --
>> 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
>
>
--
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
