Check for xattr support on source & destination file system and inform the user (was: Preserve xattr by default?)

[Germar]

xattr seems to becoming more useful everyday as it's being used by more applications to store data on them, for example for tagging purposes. This is a good reason to have future versions of BIT preserve xattr by default.

Here is a list of examples that use xattr to store tags:

• KDE 4.13 http://vhanda.in/blog/2014/07/tagging-your-files/
• OS X 10.9 http://arstechnica.com/apple/2013/10/os-x-10-9/9/

Of course preserving xattr by default would be problematic in cases where the filesystem wouldn't support them

With a preliminary check on wikipedia, one can see that there is xattr support in the following cases

Linux: ext2, ext3, ext4, JFS, Squashfs, ReiserFS, XFS, Btrfs and OCFS2 1.6

OS X: HFS+ since 10.4 (since 10.6 Cocoa applications don't preserve xattr on save e.g. TextEdit, Preview)

Windows: FAT, HPFS, and NTFS (limited support I think)

https://en.wikipedia.org/wiki/Extended_file_attributes

Additionally NFS doesn't support xattr nor has any plans to do so according to a mailing list I found where the devs were against it: http://comments.gmane.org/gmane.linux.nfs/53259

A notable case worth mentioning is GNOME Tracker which doesn't use xattr to store tags (it stores them only in the database used for indexing and querying with the exception of special cases like images where it uses EXIF tags alongside the database). I had a chat on IRC with martyn, the main dev of the project and he told me that he didn't like it that way and that he would prefer if in the future Tracker would also store tags in xattr in addition to the database.

Finally there have been reported cases of problematic support of xattr one should be aware of and were solved in the past by adding the option to enable/disable it:

https://bugs.launchpad.net/backintime/+bug/571894 https://bugs.launchpad.net/backintime/+bug/489380

---

Imported from Launchpad using lp2gh.

• date created: 2014-07-10T15:27:56Z
• owner: palasso
• the launchpad url was https://bugs.launchpad.net/bugs/1340266

[Germar]

(by germar) There should be a check if destination FS supports acl and xattr and warn/deactivate the option in that case.

[MatNieuw]

I use BIT to backup to an JFS partition, because that supports 64k xattr, and some of my partitions are OS/2, and have some programs using almost the full 64k. I tested a backup, then renamed the original, and restored it from the BIT backup, and the 64k xattr came right back. This did not work when backing up to ext4. It is something to keep in mind, the kernel supports 64k xattr, but according to ¨https://en.wikipedia.org/wiki/Extended_file_attributes¨ XFS and ReiserFS support this, JFS does it too. Other file systems look to have a 4K limit. Maybe BIT should look at the file systems of partitions to be backed up, and the destination, to see if there is a mismatch which would cause losses of xattr.

[buhtz]

So, allow me to summarize this 10 year old issue:

• If xattr (a switch in rsync) is working or not depends on the filesystems used.
• It seems also that rsync does not give an error if xattr is active but not supported by destination.
• By default BIT do not use the --xattr rsync option.

The feature we need for BIT:

• Check if the destination and source(!) do support xattr. (on every create profile or change snapshot folder action)
• If it is supported on both sides offer to enable that option to the user via a separate message dialog.
• Keep the option off/False by default to not interfere with existing profiles.
• Disable the checkbox if xattr support is not possible.

Any others suggestions?

How to check? To my research:

• Rsync will warn if the destination do not support xattr. But...
• Rsync do not warn or error if the source do not support xattr.