finderInfo of the Spotlight directory files.

finderInfo of the Spotlight directory files.

[Hin-Tak Leung]

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 - 

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

Re: finderInfo of the Spotlight directory files.

[Vyacheslav Dubeyko]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: finderInfo of the Spotlight directory files.

[Hin-Tak Leung]

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: finderInfo of the Spotlight directory files.

[Vyacheslav Dubeyko]

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.

Re: finderInfo of the Spotlight directory files.

[Hin-Tak Leung]

Hi Vyacheslav,

Since user_info and finder_info are entirely C structs, and always there,
and also does nothing useful under linux, I think we should
just serve them out whatever content it contains. content all nulls is legal,
and in fact the spotlight hidden files have them that way.

One useful thing is to see what mac os x does - I suspect it serves
them out as is, since finderinfo are always show as hex from the
google'ing I do.

Also the root node itself returns the same error - I haven't looked at that
one yet; but anyway, not having any attributes is not an error.

I don't feel strong either way since it only affects a few special nodes which have
no meaningful use to the finder.

As for the other issue, it is just that I notice linux-created files shows
gabbage creater/file type. The problem isn't in the checking code, but in 
the writing code. I think somebody else did fix recently (a few months/a year ago)
issues with gabbage in other part of user_info/finder_info which are meaningful
to finder [1] ; but perhaps there is no meaningful setting to creater/file type
- I just wish they aren't random gabbage.

[1] https://lkml.org/lkml/2012/9/14/298

Hin-Tak

--------------------------------------------
On Mon, 14/4/14, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

 Subject: Re: finderInfo of the Spotlight directory files.
 To: "Hin-Tak Leung" <htl10@users.sourceforge.net>
 Cc: linux-fsdevel@vger.kernel.org
 Date: Monday, 14 April, 2014, 17:19
 
 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html