Was already looking for where it is planned (and discussed). Sadly didn’t find much here or any meta tickets or similar. Maybe you can point me to correct discussion/ticket?
Thank you for your work. 
There is not much discussion, just a short wiki page about limitations of BFS: FutureHaiku/BFSIssues – Haiku
Certainly this could benefit from more details. Personally I don’t know enough about BFS structure to understand most of it.
2 Likes
Don’t get me wrong. People are doing a good job working on different topics. But this specific one seems to be one nobody is actually doing something but everyone having an opinion on how not to do it. 
I’m just not sure of this is not just everyone blocking everyone from moving.
If the goal is to just improve what is there: Specific tickets should be opened and someone should work on them one by one. This would however in no way interact with what this thread is about.
If the goal is to make something that is new: Then people must accept it to break with old ideas and maybe not matching such lists at all. I mean half of that list is about specific data structures that would not be present in a new design to begin with.
Or maybe both is wanted or needed, but then the teams need to figure out each their own topics in their own threads.
Maybe it’s also about people fear that having something new will remove what is there already. History has shown: no, the pile is just getting bigger.
Everyone have a good day!
1 Like
I was thinking about a few things recently (in different contexts). And I think I stumbled over two things that could improve database-ness a good bit with very little code changes:
The first would be to support POSIX O_EXEC and O_SEARCH, as well as Linux’s O_PATH. They are all basically aliases (POSIX specifically/explicitly allows to use the same value for all of them). If set in open() (and friends) they open the file for filesystem functions but no data functions. This allows them to be used e.g. for *at() calls without the need to get them to the point you can actually do I/O. Plus the topic of permissions is slightly different.
In Haiku this is already a thing. Haiku however uses the classic model of O_RDONLY with O_RDONLY=0. What I would do here is to add the constants tu the corresponding header and reserve a bit for it. Also check in the kernel about that bit and kernel-land alias that to O_RDONLY (which is a superset of O_EXEC/O_SEARCH/O_PATH, therefore a safe kernel land aliasing).
This change will also improve general POSIX and Linux compatibility with likely less than 10 lines of code change.
The second change would be to support data sets that are not classic files in the filesystem. Those files would be always zero bytes (just like for example sockets, fifos, device files, …). The sole purpose is to use them to store extended attributes plus keeping the inode alive (with the inode number being the primary index for the filesystem basically, so making them a true inode makes them first class citizens, just like extended attributes and stuff).
This is already “the Haiku way”, see e.g. Person files.
This would mean to define a new inode type (within S_IFMT, which might need to be adjusted). It would break the binary compatibility towards old code (but not towards newer code). In the most simple case the kernel would only need to check that no write is ever done to such an inode. Any filesystem checking would check that they are 0 byte (and if not allow to convert them to a plain file or delete the data).
Creation could be done via mknod() (and friends). Also there could be an ioctl() or similar to convert an existing 0 byte plain file to the new type.
I think that those two changes together would bring the most improvement at the lowest work right now. And specifically the first one would clearly also be good as it would improve POSIX compatibility at basically no cost at all.
What is still missing is proper references. Maybe at some point an extended metadata could be referencing another inode. I don’t think that would be much of the problem. However it might need full hardlink support first.
As always, happy to discuss here or on IRC. Also happy to provide/discuss specific patches.
4 Likes
I am not really sure what the second change is intended to achieve over what can already be done with a zero sized file with attributes?
References are something @grexe is working on I believe. **ANNOUNCEMENT** SEN + Personal Knowledge Graphs Book featuring Haiku
1 Like
A bit offtopic, but still.
In exactly your use case I would keep the original files intact and rather create symlinks to each document I touch. Then I can rename these links, re-arrange them in whatever folder structure etc. Symlinks do not take (much) space on disk. In case of Windows, for the same purpose there are *.lnk files, which can be sorted in similar manner.
1 Like
You need softlinks for that,not hardlinks.
Softlinks will do exactly what you expect,they’re just a pointer to the actual file.
1 Like
Your problem seems to be more with MS Office and its files. In Windows 7, a hard link shows the size/dates as you want, and a soft link doesn´t.
But Office will save your modifications on a temp file, delete the original one, then rename the temp file to the old name. In this, the “linkage” is broken.
If what you want is just a way to backup those files, a full backup will be easier, and work better. No need to worry about damaging the destination storage, but if you really insist, a normal hard disk is pretty cheap nowadays.
The difference is that a zero byte file is still… a flat file. This would be to indicate that something is not a flat file and does not have flat file semantics. Otherwise I could ash why for example device inodes are not just zero byte files with attributes.
The point is that, while they [flat files and the new type) share some properties, aren’t the same kind of thing. Just as with device inodes. It would also allow the kernel to enforce those different semantics.
Yes I can see that from what you wrote before. But your posts suggest that this (breaking) change has some benefits or advantages, without actually explaining what they are?
Would a database file system be useful for forum server software?
Each post in every threads are independent files using metadata to indicate different properties including thread, linkage, file attachment status, and even “keywords” generated by AI.
With improved forum server file system, old posts are easier to be traced instead of remaining scattered info in the forum. You see how some topics periodically arise this forum because old related posts cannot be easily found. For some other forums with older forum software, the issue is worse.
However this is an extremely difficult task on Haiku given Haiku itself is a desktop OS but not a server OS.
I see a potential use case. Imagine hundreds of photos, and looking up certain aspects like motif, location etc.
About the DB FS: How about using tags? (could be done with Unix groups I guess). Then you could query using these tags.
it probably doesn’t need each thread or post to be accessible as a plain file. So, you could just use a normal database, that does not also try to be a filesystem, and your life will be simpler. Which is what all existing forum software already does.
2 Likes
Mr. Codda (the father of SQL) created relational databases that have nothing to do with file systems. They were NOSQL index databases, primarily based on JSON.
Please don’t confuse file systems with databases.
Currently, the Btrfs file system is the most popular in the open source world.
Please don’t confuse file systems with databases.
IBM IMS is quite similar to a file system. Please do not confuse databases with relational databases.
Practically, you can create a file system in a database on blobs, but why would it be terribly slow?
Idk what the befs performance is like but this thread exists because befs is unique in that it does already support database like file attributes and indexing. So it would be faster than on other filesystems using xattr.
From Be File System - Wikipedia :
Like its predecessor, OFS (Old Be File System, written by Benoit Schillings - formerly BFS),[4] it includes support for extended file attributes (metadata), with indexing and querying characteristics to provide functionality similar to that of a relational database.
1 Like
That is precisely my first consideration when replacing a file system with a database.
OFL had a separate database synchronized with the file system. When the BeBox team migrated from the Hobbit CPU to PPC, they created BFS and simply added database features to the file system to avoid synchronization issues, slow speed, and data corruption problems. BUT it doesn’t have all the features of a file system, nor all the features of a database.
The biggest problem is POSIX. You can’t mix traditional file path calls and database queries at the same time. Actually, you can, but it would be like shooting yourself in the foot.
Just look at this example:
// Traditional BFS:
open(“/home/docs/report.txt”);
// BFS as DB:
query(“SELECT * FROM files WHERE author=‘john’ AND created > ‘2024-01-01’”);
// WOULD DIE: open(), read(), write(), close()
// WOULD BE BORN:
db_insert(dataset, record);
db_query(“SELECT * FROM data WHERE type=‘document’”);
db_transaction_commit();
Hierarchical vs. Relational? Here’s the real dilemma.
Advantages of the pure database:
- Native complex queries.
- True ACID transactions.
- Metadata as first-class citizens.
- Flexible structure without artificial paths.
- Predictable performance.
The real cost: total incompatibility.
You would lose:
- All existing applications.
- Traditional tools (ls, cp, rm).
- Network protocols (NFS, SMB).
- “Files and folders” mentality.
But you would gain:
- A consistent and unified system.
- Performance optimized for real-world use cases.
- Simplified maintenance.
- Future evolution without constraints.
Conclusion: you have to choose.
BeFS made the mistake of trying to be both. The lesson is: a system that tries to be two things ends up being good at neither.
5 Likes
Would a wrapper for certain application-specific purposes be a worthy, workable solution?
You mean a file system “driver”/code ontop of a database? Then you can operate on the database like on a directory. But as there already exists the possibility to use SQL commands there’s no need for it.