Re: finderInfo of the Spotlight directory files.

[Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxx> wrote:

 Subject: Re: finderInfo of the Spotlight directory files.
 To: "Hin-Tak Leung" <htl10@xxxxxxxxxxxxxxxxxxxxx>
 Cc: linux-fsdevel@xxxxxxxxxxxxxxx
 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html