divided into several parts, it could happen that overwrite the whole data
portion with data beyond the part that should have been read.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9706 a95241bf-73f2-0310-859d-f6bbb57e9c96
a comment that explains why the other TTY has to be chosen there.
Improved debug output.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9698 a95241bf-73f2-0310-859d-f6bbb57e9c96
was running. Thanks a lot to Jerome Duval who found this!
Since TTY ECHO mode doesn't look too well with the old shell, it will directly
start "sh" now, which should be the bash.
No longer prints out the TTY used when started, but now sets (as usually
done in BeOS) the TTY environment variable.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9697 a95241bf-73f2-0310-859d-f6bbb57e9c96
manager - note, this currently does not until the different module
APIs for file systems are merged together.
fs_mount_volume()'s order of arguments was changed.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9696 a95241bf-73f2-0310-859d-f6bbb57e9c96
Removed the fs_initialize_volume() function, as it's probably not going
to be needed.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9695 a95241bf-73f2-0310-859d-f6bbb57e9c96
there is no reason to let it appear important by having it as first
parameter; it's only used to override the DDM's decision if the user
so choses.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9694 a95241bf-73f2-0310-859d-f6bbb57e9c96
absolutely no reason to move them to B_SYSTEM_TEAM (additionally, during
startup, set_sem_owner() may crash).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9693 a95241bf-73f2-0310-859d-f6bbb57e9c96
Changed the last argument of _kern_mount() to be a string rather than a void pointer.
Greatly reduced the stack usage of _user_mount(); it now uses KPath instead
of on stack paths. It now also copies the parameter argument on the heap.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9692 a95241bf-73f2-0310-859d-f6bbb57e9c96
and don't open foo again if it's running and we have files to give it.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9675 a95241bf-73f2-0310-859d-f6bbb57e9c96
the Spam Filter enables on any of his accounts does not seem to be a good way
to determine if we should show the Spam icon or not. Maybe we should check if
the Spam Server is available?
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9674 a95241bf-73f2-0310-859d-f6bbb57e9c96
To use this feature run StatCacheServer somewhere in the background.
The first run of jam will be slower, but subsequent ones will usually
benefit. Only little, if the BeOS FS cache is able to hold the data,
but as soon as the number of files and directories jam has to inspect
hits the limit at which the cache drops data needed for the next run,
the performance difference will be very noticeable.
E.g. the time for a "jam -n > /dev/null" in the root of a partially built
tree on my machine dropped from >1 min without the server to 13 secs
with it (not in the first run, of course).
Although tested quite a bit, I would still consider the feature
experimental.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9671 a95241bf-73f2-0310-859d-f6bbb57e9c96
A bug in the function reading the cache file caused everything after a
file beginning with an empty or comment line to be ignored. Since our
Jamrules begins with a comment and only after reading Jamrules the cache
starts to work anyway, it indeed had no effect at all.
Added some error output in case reading the cache file failed, so that
this can't happen unnoticed again.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9659 a95241bf-73f2-0310-859d-f6bbb57e9c96
