A simple support for detecting BeFS (BeOS) filesystem with fstyp cli command
|7 ↗||(On Diff #87936)|
bfs.c is out of order
It's not needed anymore.
Also, you may consider adding SPDX-License-Identifier: BSD-2-Clause-FreeBSD.
|14 ↗||(On Diff #87936)|
Could you move it to the top to preserve the alphabetical order?
|289 ↗||(On Diff #87936)|
This seems to be slightly out of order.
|54 ↗||(On Diff #88071)|
wonder if we should provide a define (e.g. BFS_SUPER_BLOCK_OFFSET) for 512.
|61 ↗||(On Diff #88071)|
why bzero() the buffer if we are going to overwrite with nul-terminated string anyway?
|62 ↗||(On Diff #88071)|
no magic is needed for the 3rd argument, it should be exactly the size of provided buffer
Thank you. I will go for the name BeFS because I noticed other things using this name, like sysutils/bfs or other operating systems using bfs for something else, so to make it clear, BeFS sounds good to me.
Yes please. BFS is way too generic and we had experienced name clashes in the past because they were too short. Even better if it could be done consistently, i.e. applied to macros like BFS_OS_NAME_LENGTH and BFS_SUPER_BLOCK_MAGIC1.
No. those are documented in Practical File System Design with the Be File System, and we should match their definition. Section 4.8 recommends B_OS_NAME_LENGTH, Alternatively we could use the Haiku definitions.
BTW, it would be nice if we could use other fields from the superblock, but I have no time to investigate whatever other fstype filesystems use.
Agree, the validation or identification of the file system needs to be with one or two magic fields, since it is just fstyp I though one is enough, it is not altering the fs so. And for the naming Haiku uses BFS and not exactly following the naming of the PDF, not strictly as you mentioned.
|42 ↗||(On Diff #88324)|
The API documentation is defined this way, and every other system that implemented it are using this way as constant and only defining the int32_t at the structs.