I’m still feeling my way around Haiku, finding out what it can do.
I’m wondering how the BeOS and Haiku veterans on the board are using the file attributes of BFS in their everyday lives. The People app is a good one of course. And maybe adding metadata to MP3 files using file attributes is another. Are there any other good ways to make use of the file attributes?
Native email apps store emails as files with lots of attributes, allowing querying for sender/time span/etc searches.
mp3 attributes allowed the exceptionally advanced for its time Be In Your Stereo home audio jukebox product
There’s also Trackerbase which I believe is quite interesting but I never used
For images you can add resolution, color depth, location, person, time of photo capture. You can freely add any additional information to various files about those files.
Everything listed above, but all that was already available on BeOS. If new native programs like Medo are making innovative use of attributes, I’m not aware of it (and that is as it should be btw: it should be transparent to the end-user).
For the last ten years, we’ve been more invested in porting than in native programs, so a lot of available programs store data in SQLite databases that could theoretically have been placed in attributes. But that phase seems to be ending, @grexe’s work is giving us a new look at attributes, and we are starting to emphasize native apps in the Haikudepot site and soon in the app.
A PDF library could also benefit from file attibutes. I thought there was a document about a sample PDF library using file attributes, but I could not find it…
(Edit) Looks like I was confused. This one should give you a good idea:
Yes it’s a shame that even native Haiku apps don’t make use of the built in database and instead draw in completely unnecessary dependencies and legacy.
People need to understand what made BeOS truly unique wrt to the file system that other “modern” operating systems still don’t support, not even rudimentary.
I did some research and the closest alternative for building SEN on would be MacOS, which is no wonder since Dominic Giampaolo who wrote most of the Be file system later worked at Apple and implemented most of modern AFS and spotlight.
But even MacOS Finder doesn’t support the elegant custom attribute view of Tracker where you can display them in columns. So whenever a Haiku app decides to warden the data in some proprietary format it makes me sad. This feature is totally under valued and under advertised, and I want to change that.
I’m currently wrapping up SEN but it took me longer since I had to refactor some core stuff to make it easier to extend later. Still aiming for end of 2025 with a possible gift from SENta clause, stay tuned.
I’m curious what apps you mean by that? Shipped native apps usually work like that. For example Mail uses attributes from people files, regardless of where they are stored.
I know the “Calendar” app for example doesn’t? but then that is in HaikuArchives and not ready in any case (Should for example have files for apointments you could literally drag and drop into Mail for icard invites, but that is future music…)
Besides the obvious, visible usage like showing email fields, image resolution, bookmark url/title/keywords - and the really powerful feature of queries and type-ahead filtering - there’s also the ‘hidden’ usage. For example, I love to use font styles and colours in plain text files like ~/config/settings/profile and scripts etc. (ETA: that formatting info is stored in attributes)
It would be nice to have a Haiku text/generic+zip file format like this, so that attributes would be preserved even in non-BFS file systems.
that won’t work. The idea here is that “Only plaintext” formats like some configs can support styling like this, if you just shove a zip there then the executable that is actually supposed to read the file won’t be able to understand the zip archive
This should be a special zip format (.hz?) that is “transparent” to Haiku, say, like a mini bfs volume or something similar. When Haiku reads such a zip file, it should unarchive it in memory and run the file it contains according to its type.
Seems like something that would make more sense on the level of a filesystem mount itself then, similar to how macos does attribute emulation
If i may offer an opinion as to why that is: files which cannot be copied from system to system are largely pointless. An SQLite db (mentioned in another response) holding metadata can be freely copied to any OS and read there. Filesystem-specific attributes can’t even be copied to an exfat-formatted SD Card on the same system.
As interesting as extended attributes are, they’re not portable and therefore, largely, not a practical solution because they’re stuck on the system hosting them. Few IT professionals/die-hards work exclusively with a single OS and most of their problems want/need cross-system solutions.
0.02€ and all that.
It’s very unlikely that you ever need to copy program data that’s somewhere in ~/config or some hidden .folder
Usually you can export that data into a common format that other applications also understand before you sync it to another system.
For that typical use case,I doubt you notice a difference whether the program internally stores its data in a SQLite database or Haiku-native attributes.
As an end user, no, but as developer who wants their software to be (no pun intended!) portable, extended attributes are an obvious no-no. No developer wants to maintain something like file metadata in multiple formats. It’s JSON or YAML or SQLite.
If you want to make your software portable,you probably also won’t make it Haiku-native using the BeAPI and instead use something like Qt or GTK.
If you make it with BeAPI,you can safely expect that it’s always used on Haiku and filesystem attributes are supported,too.
Now that Cosmoe is porting the Haiku API to Linux, the Haiku API can become another option like Qt or GTK.
Does it mean though that all the info in my People folder (apart from the person’s name) will automatically disappear if exfiltrated to any non-BFS file system?
Security through obscurity?
This has nothing to do with security through obscurity. But yes, if you copy the files to a filesystem without attributes, the attributes will be lost. Tracker should probably warn about it; but I think it doesn’t currently.
Many file systems actually support extended attributes. However, I’m not sure copying the data would actually preserve them, as extended attributes are untyped, and you would need some kind of translation layer. This is what the Haiku build system uses to have attributes on files generated on the non-Haiku host system (there is an alternative option to store them separately as files, though, for file systems that don’t support them at all or not good enough).
Anyway, if you want to be safe, you would need to ZIP your people files before moving them to another system.
On the topic of common uses, I have a collection of movies that I enrich with attributes like movie ratings, IMDB votes and ID, etc. with a couple of scraper scripts. That way I can search, for instance,ä for PG13 movies that don’t exceed a certain run time right in Tracker.