No I do not believe that either the native HFS+ driver or the Paragon software HFS+ products support extended attributes.
According to the HFS+ Wikipedia page the status of these drivers is every basic in the features that they support and have been known to corrupt HDDs in certain situations.
excerpt from CentOS thread
On Wednesday, March 07, 2012 01:17:15 PM Wessel van der Aart wrote:
so i add user_xattr and acl to my fstab options but then it fails to mount.
checking the error in dmesg just gives me ¨hfs: unable to parse mount
options¨.
does anyone know what´s going on and what i should do to make this work?
Well, having used the in-kernel HFS+ filesystem driver before, and
found it lacking in a number of areas (like massive corruption under
heavy load or when unlinking lots of files) I bought the commercially
supported Paragon NTFS&HFS drivers.
excerpt from CentOS thread
i tried their free version today. at first it did look promising but
as soon i was to perform actions on files with acl's on them the
whole system came down hard and leaving my external HDD corrupted.
after several hours i've decided to give up and go with ext4 but still
thanks!
References
The append only flag (chattr +a) prevent from removing the directory, a well as files and directories created directly inside that directory:
Create test directory and files:
# mkdir /tmp/foo
# chattr +a /tmp/foo
That directory can't be deleted:
# rmdir /tmp/foo
rmdir: failed to remove ‘/tmp/foo’: Operation not permitted
Now create files and directory inside it:
# touch /tmp/foo/bar
# mkdir /tmp/foo/baz
Let's inspect that:
# lsattr -d /tmp/foo /tmp/foo/ba*
-----a-------e-- /tmp/foo
-------------e-- /tmp/foo/bar
-------------e-- /tmp/foo/baz
Try to erase stuffs:
# rm /tmp/foo/bar
rm: cannot remove ‘/tmp/foo/bar’: Operation not permitted
# rmdir /tmp/foo/baz
rmdir: failed to remove ‘/tmp/foo/baz’: Operation not permitted
rm -Rf /tmp/foo
rm: cannot remove ‘/tmp/foo/bar’: Operation not permitted
rm: cannot remove ‘/tmp/foo/baz’: Operation not permitted
Finally, sub-sub-directory and files in sub-directories are not protected:
# mkdir /tmp/foo/baz/bat
# touch /tmp/foo/baz/baff
# rm --verbose -Rf /tmp/foo/baz
removed directory: ‘/tmp/foo/baz/bat’
removed ‘/tmp/foo/baz/baff’
rm: cannot remove ‘/tmp/foo/baz’: Operation not permitted
Again, note that only /tmp/foo had the append flag:
# lsattr -d /tmp/foo /tmp/foo/baz
-----a-------e-- /tmp/foo
-------------e-- /tmp/foo/baz
Best Answer
No, those flags are set using the
FC_IOC_SETFLAGSioctl()(also known asEXT2_IOC_SETFLAGSforext*file systems, and corresponding one for other filesystems).In most file systems that support it, that translates to one bit map of the inode structure.
For instance, in
ext4and several other file systems, that's thei_flagsinode structure member (a 32 bit integer).Some foreign (non-Linux) filesystems like Apple's HFS+ have a similar concept with equivalent flags and the
FC_IOC_SETFLAGSioctl does the translation there.When using the
statcommand (which dumps the inode structure) indebugfsonext*file systems, that's theFlags:number in the output:0x80000 is
FS_EXTENT_FL(einlsattroutput), 0x10 isFS_IMMUTABLE_FL(i).The new
statx()system call can also return (part of) that information (not all systems at this time (early 2019) will have a recent enough version of the GNU libc (2.28 or newer) to be able to call it easily though).On a recent system, you can use
xfs_io'sstatxcommand as an interface to thestatx()system call:(here 0x10 is
STATX_ATTR_IMMUTABLE, theFS_EXTENT_FLone doesn't have a correspondingstatx()flag).