------------------------------ On Mon, Sep 23, 2013 07:33 BST Vyacheslav Dubeyko wrote: >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. "...during mount...", first sentence, 2nd paragraph. >> 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. I meant the generic user-invoked "copy" operation. AFAIK (first hand experience?), drag-and-drop from Finder does copy some xattrs/rscs ; and I seem to remember have came across an enhancement patch for rsync which does that too, which has either been merged upstream or shipped-as-patched. While the command-line 'cp' does not do it by default, isn't there an option for doing it? 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
