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
devfs_read_link() and rootfs_read_link() could write beyond the buffer
size passed in (off by one).
The comment for _kern_read_link() didn't fit to what the function really
did.
common_read_link() no longer null terminates the link - it's the file
system's responsibility to do that.
fs_read_link() is not supposed to return the length of the link anymore,
but only B_OK for success.
Note, we deviate slightly from POSIX here, where even a buffer too small
would be filled, and no terminating null byte has to be written at all.
We always return an error in case the buffer is too small, and the link
is not partially copied into the buffer.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9652 a95241bf-73f2-0310-859d-f6bbb57e9c96
that are short enough to be placed in the short symlink region.
bfs_read_link() now makes sure that the link read is always null terminated.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9650 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now we free() the run_array allocated by "RunArray()" (as we're supposed to do), thus removing a leak.
Changed some includes from <> to "" just for my personal pleasure.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9648 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashed when used with our BTextView if the STELine struct was 12 byte in size, was just because
libtranslation.so was using BeOS's BTextView, where the size of that struct is 16. In fact, linking against our
libtranslation.so doesn't avoid the crash, while compiling that lib against our BTextView and then linking
against it makes the crash disappear.
Changed the comment near that struct.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9646 a95241bf-73f2-0310-859d-f6bbb57e9c96
Made the FS internal API a bit more consistent.
Removed devfs_unlink(), and devfs_rename() (which was just returning EROFS
anyway) - the devfs now appears completely read-only to the user. All
changes are triggered by kernel internal APIs (most usually through either
the devfs itself (old style drivers), the disk_device_manager, or the
standard device_manager).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9645 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also implemented the now needed devfs_read_link() function.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9644 a95241bf-73f2-0310-859d-f6bbb57e9c96
