| #
5f4f455c |
| 02-Feb-2020 |
Kyle Ambroff-Kao <kyle@ambroffkao.com> |
test/storage: Fix BFile tests
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 "UnitT
test/storage: Fix BFile tests
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>
show more ...
|