Hacker News new | past | comments | ask | show | jobs | submit login

Extended attributes are messy. E.g. the equivalent on Windows (ADS, not EA, which also exist separately) can store arbitrary amounts of data, I'd expect resource forks on macOS to be similar. Meanwhile Linux only supports 64 KB of data for them, though most Linux-native file systems have an even lower one block limit. And then there's Solaris where extended attributes are actually an FS namespace.

So even if both file systems support extended attributes, does not mean that you can actually preserve them.




>Meanwhile Linux only supports 64 KB

Yes, absolutely true, thanks for the addition:

-Linux max 64kb (some filesystems just 4k)

-HFS+ max 128kb, But MacOS theoretically supports up to 64MB!

-FreeBSD max 64MB with UFS2 or ZFS

-Windows 65536 bytes with NTFS

So from BSD (MacOS) to BSD should/could work.

Truly messy stuff :)


So build your own NAS on BSD+ZFS and use rsync w/xattr's? Not a bad solution theoretically...


Keep in mind that your mounted NFS needs to support xattrs too :)

mount -t nfs -o user_xattr

I just found out that ~only? the Solaris/illumOS NFS-server supports that, and the Linux Client since Kernel 5.9

With all that information..i honestly would just make a dump of my FS and backup the dump, terrible i know.


This is the advantage of the "newfangled" backup tools which don't just copy files from A to B and can do (but not always do!) a much better job at a) not caring about your backup destination's file system b) not losing data that's more complicated than "name and contents".




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: