Re: [PATCH 3/3] hfsplus: implement attributes file creation functionality

[Vyacheslav Dubeyko <slava@dubeyko.com>]

On Fri, 2013-09-20 at 23:30 +0100, Hin-Tak Leung wrote:
> --------------------------------------------

[snip]
>  
>  This patch implements functionality of creation
>  AttributesFile metadata file on HFS+ volume in the case of absence of it.
>  
>  It makes trying to open AttributesFile's B-tree during mount
>  of HFS+ volume. If HFS+ volume hasn't AttributesFile then a
>  pointer on AttributesFile's B-tree keeps as NULL. Thereby, when it
>  is discovered absence of AttributesFile on HFS+ volume in the
>  begin of xattr creation operation then AttributesFile will be
>  created.
>  
>  The creation of AttributesFile will have success in the case
>  of availability (2 * clump) free blocks on HFS+ volume.
>  Otherwise, creation operation is ended with error (-ENOSPC).

[snip]
> 
> The changelog isn't quite correct/precise. According to the code (my reading and
> understanding of it), The AttributesFile is created on first need, i.e. when the first-ever
> attribute is set. The changelog sounds as if an empty one might be created
> if missing, on mount. The latter would be somewhat undesirable, as a user might
> just keep a particular disk quite full but contain entirely of plain no-attribute files, and
> have no need of a big AttributesFile ever, and suddenly find a disk throwing an previously-not-seen
> error on use.
> 

I don't think that description of the patch set is inaccurate. And I
misunderstand how you can conclude from path set description that
AttributesFile is created during mount operation. The patch description
states that HFS+ driver tries to open AttributesFile's tree by means of
hfs_btree_open() call (but such call takes place only if total blocks of
AttributesFile doesn't equal to zero). So, hfs_btree_open() method
doesn't contain any code of creation AttributesFile. And, finally,
description of the patch states that AttributesFile creation
functionality can be called in the begin of operation of extended
attribute (xattr) creation, namely, in __hfsplus_setxattr() method.

> Usage on linux would mostly be standalone xsetattr; the other common use would be
> the copy of a file plus its attribute, from another fs which supports this, to an hfs+ fs without
> a  AttributesFile yet. How does hfs+ under Mac OS behaves vs current Linux vs patched Linux?
> (silently dropping attribute/drop attribute with warning/error/etc ?)

As far as I can judge, Mac OS X doesn't copy xattrs of files during
copying operation. And, as far as I can see, Linux does it in the same
way. Anyway, a file system driver should have some set of method for
xattrs support. And HFS+ driver has all necessary methods (for xattrs
support) as implemented.

With the best regards,
Vyacheslav Dubeyko.