[PATCH v2 0/4] hfsplus: reworked support of extended attributes

[PATCH v2 0/4] hfsplus: reworked support of extended attributes

[Vyacheslav Dubeyko]

Hi,

This second version (v2) of patch set adds real support of extended attributes in HFS+ file system.

v2->v1
* It was fixed the issue with message "No such file or directory" generation before outputting the expected result for "ls -l".
* It was fixed the issue with wrong 'hfs: xattr searching failed' kernel message generation in the case of real extended attribute absence for requested name.
* It was fixed the issue with checking of necessity to show com.apple.FinderInfo in the list of available extended attributes.

Current mainline implementation of hfsplus file system driver treats as extended attributes only two fields (fdType and fdCreator) of user_info field in file description record (struct hfsplus_cat_file). It is possible to get or set only these two fields as extended attributes. But HFS+ treats as com.apple.FinderInfo extended attribute an union of user_info and finder_info fields as for file (struct hfsplus_cat_file) as for folder (struct hfsplus_cat_folder). Moreover, current mainline implementation of hfsplus file system driver doesn't support special metadata file - attributes tree.

Mac OS X 10.4 and later support extended attributes by making use of the HFS+ filesystem Attributes file B*-tree feature which allows for named forks. Mac OS X supports only inline extended attributes, limiting their size to 3802 bytes. Any regular file may have a list of extended attributes. HFS+ supports an arbitrary number of named forks. Each attribute is denoted by a name and the associated data. The name is a null-terminated Unicode string. It is possible to list, to get, to set, and to remove extended attributes from files or directories.

It exists some peculiarity during getting of extended attributes list by means of getfattr utility. The getfattr utility expects prefix "user." before any extended attribute's name. So, it ignores any names that don't contained such prefix. Such behavior of getfattr utility results in unexpected empty output of extended attributes list even in the case when file (or folder) contains extended attributes. It needs to use empty string as regular expression pattern for names matching (getfattr --match="").  

For support of extended attributes in HFS+:
1. It was added necessary on-disk layout declarations related to Attributes tree into hfsplus_raw.h file.
2. It was added attributes.c file with implementation of functionality of manipulation by records in Attributes tree.
3. It was reworked hfsplus_listxattr, hfsplus_getxattr, hfsplus_setxattr functions in ioctl.c. Moreover, it was added hfsplus_removexattr method.

With the best regards,
Vyacheslav Dubeyko.
---
 fs/hfsplus/Makefile      |    3 +-
 fs/hfsplus/attributes.c  |  388 ---------------------------------
 fs/hfsplus/bfind.c       |   79 +------
 fs/hfsplus/bnode.c       |    6 +-
 fs/hfsplus/brec.c        |   23 +-
 fs/hfsplus/btree.c       |    8 -
 fs/hfsplus/catalog.c     |   36 ++-
 fs/hfsplus/dir.c         |    6 +-
 fs/hfsplus/extents.c     |    4 +-
 fs/hfsplus/hfsplus_fs.h  |   41 +---
 fs/hfsplus/hfsplus_raw.h |   72 +-----
 fs/hfsplus/inode.c       |   13 --
 fs/hfsplus/ioctl.c       |  542 ++++++----------------------------------------
 fs/hfsplus/super.c       |   36 +--
 fs/hfsplus/unicode.c     |    7 +-
 15 files changed, 124 insertions(+), 1140 deletions(-)
--
1.7.9.5

Re: [PATCH v2 0/4] hfsplus: reworked support of extended attributes

[Vyacheslav Dubeyko]

Hi Hin-Tak,

Could you test this version of patch set?

Thanks,
Vyacheslav Dubeyko.

On Sep 23, 2012, at 6:48 PM, Vyacheslav Dubeyko wrote:

> Hi,
> 
> This second version (v2) of patch set adds real support of extended attributes in HFS+ file system.
> 
> v2->v1
> * It was fixed the issue with message "No such file or directory" generation before outputting the expected result for "ls -l".
> * It was fixed the issue with wrong 'hfs: xattr searching failed' kernel message generation in the case of real extended attribute absence for requested name.
> * It was fixed the issue with checking of necessity to show com.apple.FinderInfo in the list of available extended attributes.
> 
> Current mainline implementation of hfsplus file system driver treats as extended attributes only two fields (fdType and fdCreator) of user_info field in file description record (struct hfsplus_cat_file). It is possible to get or set only these two fields as extended attributes. But HFS+ treats as com.apple.FinderInfo extended attribute an union of user_info and finder_info fields as for file (struct hfsplus_cat_file) as for folder (struct hfsplus_cat_folder). Moreover, current mainline implementation of hfsplus file system driver doesn't support special metadata file - attributes tree.
> 
> Mac OS X 10.4 and later support extended attributes by making use of the HFS+ filesystem Attributes file B*-tree feature which allows for named forks. Mac OS X supports only inline extended attributes, limiting their size to 3802 bytes. Any regular file may have a list of extended attributes. HFS+ supports an arbitrary number of named forks. Each attribute is denoted by a name and the associated data. The name is a null-terminated Unicode string. It is possible to list, to get, to set, and to remove extended attributes from files or directories.
> 
> It exists some peculiarity during getting of extended attributes list by means of getfattr utility. The getfattr utility expects prefix "user." before any extended attribute's name. So, it ignores any names that don't contained such prefix. Such behavior of getfattr utility results in unexpected empty output of extended attributes list even in the case when file (or folder) contains extended attributes. It needs to use empty string as regular expression pattern for names matching (getfattr --match="").  
> 
> For support of extended attributes in HFS+:
> 1. It was added necessary on-disk layout declarations related to Attributes tree into hfsplus_raw.h file.
> 2. It was added attributes.c file with implementation of functionality of manipulation by records in Attributes tree.
> 3. It was reworked hfsplus_listxattr, hfsplus_getxattr, hfsplus_setxattr functions in ioctl.c. Moreover, it was added hfsplus_removexattr method.
> 
> With the best regards,
> Vyacheslav Dubeyko.
> ---
> fs/hfsplus/Makefile      |    3 +-
> fs/hfsplus/attributes.c  |  388 ---------------------------------
> fs/hfsplus/bfind.c       |   79 +------
> fs/hfsplus/bnode.c       |    6 +-
> fs/hfsplus/brec.c        |   23 +-
> fs/hfsplus/btree.c       |    8 -
> fs/hfsplus/catalog.c     |   36 ++-
> fs/hfsplus/dir.c         |    6 +-
> fs/hfsplus/extents.c     |    4 +-
> fs/hfsplus/hfsplus_fs.h  |   41 +---
> fs/hfsplus/hfsplus_raw.h |   72 +-----
> fs/hfsplus/inode.c       |   13 --
> fs/hfsplus/ioctl.c       |  542 ++++++----------------------------------------
> fs/hfsplus/super.c       |   36 +--
> fs/hfsplus/unicode.c     |    7 +-
> 15 files changed, 124 insertions(+), 1140 deletions(-)
> --
> 1.7.9.5
> 
> --
> 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: [PATCH v2 0/4] hfsplus: reworked support of extended attributes

[Andrew Morton]

On Sun, 23 Sep 2012 18:48:50 +0400
Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

> This second version (v2) of patch set adds real support of extended attributes in HFS+ file system.

That's a lot of code in an area which few people work on.  Has this
patchset had significant review input from anyone yet?

Re: [PATCH v2 0/4] hfsplus: reworked support of extended attributes

[Vyacheslav Dubeyko]

Hi,

On Mon, 2012-09-24 at 15:49 -0700, Andrew Morton wrote:
> On Sun, 23 Sep 2012 18:48:50 +0400
> Vyacheslav Dubeyko <slava@dubeyko.com> wrote:
> 
> > This second version (v2) of patch set adds real support of extended attributes in HFS+ file system.
> 
> That's a lot of code in an area which few people work on.  Has this
> patchset had significant review input from anyone yet?
> 

Unfortunately, the patch set hadn't significant review input from anyone
yet. But it was submitted about a month ago. So, I think, it was enough
time for reviewing the patch set by anyone. Anyway, I open for any
comments or remarks.

I think that the patch set is important because it adds support of
operations with Attributes Tree. This metadata structure is widely used
currently under Mac OS X. And absence of Attributes Tree's support in
Linux kernel can lead to file system inconsistency in some situation.
Moreover, support of operations with Attributes Tree is a basis for HFS+
compressed files and ACL support.

With the best regards,
Vyacheslav Dubeyko.