After this patch "UnitTester BFile" runs with no failures. This includes some changes to NodeTest as well since the BFile suite inherits some tests from it, but "UnitTester BNode" doesn't pass yet. FileTest: * Fix format strings in log messages to use the correct types and quite warnings. * Test for expected behavior with BFile(..., B_READ_ONLY | B_ERASE_FILE) There is a table in the BFile tests which is used as input for a series of tests which construct BFile objects with various permutations of the mode parameter. For two of these, the combination of B_ERASE_FILE and B_READ_ONLY are used for the file mode. The system rejects these with the error B_NOT_ALLOWED. This is enforced in bfs_open(), which looks for that particular combination (O_RDONLY | O_TRUNC). I tested this on BeOS R5 and it will indeed let you create a BFile(path, B_READ_ONLY | B_ERASE_FILE) which basically replaces the file at path with an empty file. The Haiku behavior seems way more sensible, so I'm changing these tests to match its current behavior. * BFile(..., B_READ_ONLY).SetSize() isn't allowed. BeOS R5 allowed you create a BFile with the B_READ_ONLY flag and then successfully set the size of the file with BFile::SetSize(). Haiku doesn't, and that seems way better. Updating BFileTest::SizeTest to match Haiku behavior. One whole sub-test was removed from FileTest::SizeTest because it calls SetSize() on a `B_READ_ONLY | B_ERASE_FILE` BFile. This is redundant as other tests in this suite already verify that it is not possible to construct a BFile with that combination of flags. NodeTest: * Fix tests to match Haiku's max attribute length. Many of these tests assume that the max size of an attribute name is 255 bytes, and it was in BeOS R5, which I just confirmed. But Haiku allows 256 bytes. In 4069e1f30 some compromise was struck that allowed this to avoid breaking userspace which had been allowed to use 256 byte keys at some point. * WriteAttr, ReadAttr and RemoveAttr all return B_NAME_TOO_LONG if an attribute name longer than 256 bytes (excluding null terminator) are provided. * Disable NodeTest::AttrRenameTest since attr rename is not supported Tests in BNodeTest (inherited by BFile tests) exercize BNode::RenameAttr(), but from what I can see attribute renaming is not implemented at all. bfs_rename_attr() has a TODO comment and just always returns EOPNOTSUPP (B_NOT_SUPPORTED). And that is the value returned from BNode::RenameAttr() in these tests. So for now I made these tests just check that B_NOT_SUPPORTED is returned from BNode::RenameAttr(), so when this functionality is implemented these tests will fail and can be cleaned up. Change-Id: I6cfe90ca45f3a8afa709edc9b85e648fdc865e82 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2182 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling
.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our web-based source code browsers:
- http://xref.plausible.coop/ (OpenGrok, provided by Landon Fuller)
- http://cgit.haiku-os.org/ (cgit, provided by Haiku, Inc.)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user
). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.