Re: [RFC] ioctl vs xattr for the filesystem specific attributes

[Rob North <tzwvgwv2001@sneakemail.com>]

OGAWA Hirofumi wrote:
> Hi,
> 
> Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> 
> 
>>This patch implement an "extended attributes" (XATTR) hook in aim to read or
>>modify specific  fatfs flags' like ARCHIVE or SYSTEM.
>>
>>I believe it's a good idea  because :
>>	- PAX ( GNU replacement of tar) save and restore XATTRs, so you can make more
>>exact save of FATfs without use of specific programs.
>>	- It's an elegant means to avoid use of mattrib.
>>	- Samba can use this .
>>but CONS :
>>	- use 2 Kb of kernel memory.
> 
> 
> Bastien Roucaries <roucariesbastien@yahoo.fr> writes:
> 
> 
>>Indeed some flags are shared by many namespace for instance immutable is 
>>shared by xfs,ext2/3,jfs and by the fat ( with a special mount option). 
>>Compress also is a very common flag
>>This flags are in the "common" sub-namespace.
>>
>>But some are fs specifics for instance notail attr of reiserfs,shortname of 
>>fat.They are in the the "spec"sub-namespace
> 
> 
> I received the above email.
> 
> This read/modify the file attributes of filesystem specific via xattr
> interface (in this case, ARCHIVE, SYSTEM, HIDDEN flags of fatfs).
> 
> Yes, also we can provide it via ioctl like ext2/ext3 does now.
> 
> But if those flags provides by xattr interfaces and via one namespace
> prefix, I guess the app can save/restore easy without dependency of
> one fs.
> 
> Which interface would we use for attributes of filesystem specific?
> Also if we use xattr, what namepace prefix should be used?
> 
> Any idea?
> 
> Thanks.
> 


I like the ideas that the patch seems to propose.
Infact I'd like to see the use of xattr used for non-standard attributes
applied to all fs.
Specifically, I want to backup all partitions, and attribs from one OS:
Linux. I do not want to loose fat attributes during backup.
This would also be useful for the Wine developers.


If you haven't got a response to your questions, maybe make your own 
decisions and submit a patch anyway.


One question:
How does the patch deal with the fact that only some named xattrs are
permitted?

I see 2 options:
1. all files/dirs in fat mount posess fat-specific xattrs. These xattrs 
are initialised at file/dir create. No further attribs can be added, 
none can be deleted. the fat attribute's Boolean value is defined by 
extended attribute's value.
2. all fat-specific attribs are optional, absence/presence defines
boolean value. All operations are permitted, but can only add the
fat-specific attributes.

I prefer option 1, as it makes clear what attributes are available.