add-ons accordingly and removed the syscall.
* Removed send_notification().
* Reimplemented notify_listener(). It used the unimplemented
send_notification(). Now it has a chance to work. Note that
notify_listener() is obsolete. I would already have removed it, if
there weren't lots of FS implementations still using it (Hint!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* For B_EQUALS queries the first match would be skipped.
* Exact entry name matches were broken, since the used NameIndex::Find()
expected null-terminated keys with the \0 included in the key length
while it was fed only the raw string length.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20306 a95241bf-73f2-0310-859d-f6bbb57e9c96
Currently Archiving the Unflattened picture doesn't work, and it hangs
inside assert_local_copy(), waiting for the app_server reply...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20280 a95241bf-73f2-0310-859d-f6bbb57e9c96
the stream after Flattening. Now Unflattening works, but the picture
seems to be empty
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20270 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't show up, that means something is still broken in Flatten() or
Unflatten()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20267 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku's userlandfs. I wouldn't expect them to work very well yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20255 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers dir are used instead. Added missing <new> inclusion.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20253 a95241bf-73f2-0310-859d-f6bbb57e9c96
reason, don't see the obvious. Well, or doesn't if absent...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20230 a95241bf-73f2-0310-859d-f6bbb57e9c96
reference without being a referring entry.
* Reworked entry renaming. We do now remove the original entry first and
then create a target entry. Renaming directories didn't work before since
there would temporarily have been two links to a directory, which is not
allowed. Replacing an entry was also broken: The original entry was not
removed. Due to reversing the entry creation/deletion order we also do no
longer suffer from the Tracker bug, that entries would disappear from
queries when being renamed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20204 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added missing locking in the query hooks.
* Added live query support similarly as done in BFS:
- Volume manages a doubly-linked list of live queries.
- Volume::UpdateLiveQueries() invoked from several places where it makes
sense (standard indices, Attribute::WriteAt(), and
BVolume::NodeAttributeRemoved()) notifies the live Query objects.
- Adjusted Query to be able to deal with hard links. Unfortunately Tracker
is a bit broken with respect to hard links, particularly in the query
windows. E.g. only one entry referring to a node is shown, and the renaming
method RamFS uses (link new entry, then unlink old one) causes renamed
entries to fall out of queries, even if they should still be in.
(Want a bug report for this, Axel? :-P)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20203 a95241bf-73f2-0310-859d-f6bbb57e9c96
not-yet-mounted ClientVolume was not removed, which could cause query requests
to crash the server.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20184 a95241bf-73f2-0310-859d-f6bbb57e9c96
modifications for BONE/Dan0). As test file systems are included:
* A Reiser FS 3.6 read-only implementation (should be a virtually unmodified
version released as 1.0.1 on BeBits).
* A not quite finished RAM FS.
* A BeOS-specific networking FS. It works well as far as I've tested it, but
is utterly insecure at the moment and missing nice GUI preflets. It's also
amazingly slow which, I hope, is mainly caused by the UserlandFS layer and
BeOS R5 net server. We'll see as soon as it can be compiled for the Haiku
kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20171 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added stop_console(), a shutdown procedure for consoled (for cases
when it executes a single command only, like the debugger).
Unfortunately the system kind of freezes when the keyboard is attempted
to be closed. Entering KDL still works. It always shows consoled's
keyboard reader thread running somewhere in the endless loop in
keyboard_read() in the keyboard driver. The main thread is ready in
delete_sem() invoked by keyboard_close(), not advancing any further when
continuing the system. Apparently the scheduler needs a good spanking.
:-P
Generally it also doesn't help that the keyboard driver code is
completely cookie ignorant.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20135 a95241bf-73f2-0310-859d-f6bbb57e9c96
then the overhead of a call into libroot, and finally the overhead of a syscall
(using is_computer_on).
The numbers are totally abysmal right now. :(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20070 a95241bf-73f2-0310-859d-f6bbb57e9c96
broken (see bug #996), but less broken than Be's.
Also the Linux implementation is not perfect, as test 4 reveals: it waits for a
child with a certain process group, even if there is no child around anymore (because
the last child changed its process group. However, it will still return (and report
the correct error code) once this child exits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20009 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed comment, as Haiku now behaves properly at least for most cases :-)
* Style guide update.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20007 a95241bf-73f2-0310-859d-f6bbb57e9c96
wait() should return with an error when the process has no children
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19983 a95241bf-73f2-0310-859d-f6bbb57e9c96
another test that doesn't work on BeOS, dunno why, but who cares...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19767 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented a fibo_fork which uses fork() instead.
* Both tests can pretty easily let the kernel crash!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19764 a95241bf-73f2-0310-859d-f6bbb57e9c96
due to problems with wait_for_thread().
* Minor cleanup to the Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19757 a95241bf-73f2-0310-859d-f6bbb57e9c96
still tons of OpenBeOS references in various source files (especially in
comments), but this was more overt.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19461 a95241bf-73f2-0310-859d-f6bbb57e9c96
