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
yet, though, and just return B_ERROR.
devfs_unpublish_partition() now also returns B_ERROR since it's not yet
implemented.
Refactored the device publishing code, so that implementing devfs_publish_file_device()
will become easy.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9639 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added resolve_mount_point_to_volume_root() which does what
resolve_volume_root_to_mount_point() did. IOW the latter one didn't
do what it advertised.
* Fixed dir_vnode_to_path(). Basically broken due to the broken
resolve_volume_root_to_mount_point(), but also compared potentially
unrelated vnode IDs (belonging to different volumes).
* Fixed get_dir_path_and_leaf(). It didn't deal correctly with paths
ending in '/' (including the root dir).
* fs_mount() does now accept a NULL fsName, getting the FS name from
the DDM in this case.
* fs_mount() now also supports mounting file images; it lets the DDM
create a file device for them.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9629 a95241bf-73f2-0310-859d-f6bbb57e9c96
