mmuman
commented
5 years ago Hi, thanks for trying Haiku :-) (yes, it's just "Haiku")
I didn't try Borg yet, but I've head quite good stuff about it.
I don't have much time now to try as I already have a long list of things to port, but I can give some hints.
Attributes… well, first, Haiku's concept of xattrs (inherited from BeOS) is a bit different than the (already numerous) variants is found in *nix. First, they aren't just name/value pairs, but triplets, since they also have a type (a 32bit 4CC). This allows many interesting things like indexing them properly, storing int and float values faster than having to parse strings, and knowing how to display them properly in the GUI (with more help from the MIME database). They aren't limited in size, as they can be allocated just like regular files, although usually very small (but when cross-building Haiku on Linux we did hit the ext2 limit of 2k/inode for some apps so we added wrappers around that). Also, we make extensive use of xattrs (MIME type, preferred app, even icons…). In fact, some files, like People files (contacts) are empty files with many xattrs. So for a backup software to actually be useful on Haiku it really must support them properly.
There are dir-like functions to list a file's xattrs (fs_open_attr_dir) and read them.
Then BFS itself has indices (B+Trees based hidden directories) for the attributes we ask it to maintain. the kernel has entry points to open index as dirs, and also run queries to find files matching formulas on attributes. I don't think indices really need backuping since they are just shadow view of the fs (except maybe the actual list of indices themselves).
You'll find more infos about attributes in Storage Kit in the BeBook (oddly we don't mention the attr functions in our API Guide), Programming guides, the book describing the BFS : Practical Filesystem Design.
We do have some libattr schim around, but it's not complete IIRC. At least I recall not finding the mangling scheme very correct. Btw, it's not a Haiku-only issue, NTFS implementations on Linux also differ in their mangling schemes and screw up. I wrote a paper about properly storing xattrs on various systems for DC2011, but it seems nobody reads papers. And sadly they are always left of things like NextCloud and other things. I'm not even sure our rsync port handles them correctly. I guess I'll have to fix that myself.
Now, we don't have any concept of ACL at the moment, and no port of libacl (which was the only reason for the xattrs to ever exist before they were withdrawn from POSIX IIRC). Historically BFS had a (not really used) SYS: namespace reserved for system stuff (similar to the kernel. on ext2), which we reused for packagefs, which has SYS:PACKAGE which returns which package a file comes from.
The rest of the fs should be visible through the POSIX API. Our stat struct has some more fields like create time, that BFS maintains. BFS itself doesn't support hardlinks (because it stores the parent dir inode in the file inode to allow building the path back from dev/ino for queries).
Aside from live queries, we also support node monitoring (which BeOS had way before Linux ever had any of the inotify ancestors) with a different notification mechanism than signals though, but I don't know if it's used in Borg at all. I just wrote support for that in the owncloud client, I should publish that soon.
About gcc, we use gcc2 for binary compatibility, but unless for libs required at core level it's fine to build with newer gcc. It's handled almost like 32/64bit on linux: separate directories for libs (and sometimes headers). I usually just export PATH="/bin/x86:$PATH" but setarch x86 is fine.
Since we use headers instead of include using a common PREFIX dir for things usually never work correctly (and it's not a very good practice to assume this anyway). So it's better to be able to pass header and lib paths separately. You should be able to use pkg-config to locate openssl. Make sure you have openssl_devel installed (or openssl_x86_devel if using x86 arch so gcc > 2).
I didn't find any libb2 in HaikuPorts, but I suppose the builtin is ok.
Once you have something that builds, you'll want to try and write a HaikuPorter recipe.
Don't hesitate to come and ask on IRC.
ThomasWaldmann
Begasus
I was curious whether borg could work on haiku, so I tried borg 1.1.7 on Haiku OS R1/beta1 32bit:
borg seems to work.
I am not a haiku user, so I won't do the necessary changes to borg nor more extensive testing (nor packaging for haiku), but PRs are welcome.
Here are some notes about it for whoever wants to work on it:
I started with installing Haiku OS R1/beta1 from the ISO into VirtualBox - see their notes about installing into VirtualBox (esp. the hint about the Pro/1000 NIC card, to get a working network connection).
Then I installed some obviously needed stuff (see our docs):
python3,pip3Also installed
zstdandlz4(but guess this is not really needed as we bundle them).I didn't install
libaclnorlibattr, haiku does not have them. Also nolibb2(blake2) in haiku, but borg bundles it, so no problem.My first tries failed because it did not find the openssl headers (see code in our
setup.py).There are 2 problems:
headers/instead ofinclude/in the path component after the prefix (which is hardcoded in currentsetup.py)I hacked around them by creating a symbolic link in my home dir like
include --> /boot/.../headers/and then pointedBORG_OPENSSL_PREFIXto my home dir. :-)After that, it stumbled over the too old default gcc 2.95. The
setarch x86command fixed that, then it compiled successfully with gcc 7.I did some quick manual tests, borg init, create, list seemed to work ok.
TODO: