work to do, but it's about time to give this code more exposure.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33176 a95241bf-73f2-0310-859d-f6bbb57e9c96
It's supposed to be filled with the entry name of the directory and not as in
all the other cases used as a leaf name to be appended to the dir. This would
lead to some errors with operations based on directory fds in the build libroot
and build libbe and in the end make generate_attribute_stores fail on platforms
that don't have an 0 initialized stack (since the supplied name buffer would
contain garbage later attached to the directory path).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29227 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed fs_attr_xattr.cpp to libroot/fs_attr_untyped.cpp.
* Pulled the xattr specifics into a separate fs_attr_xattr.h.
* Added fs_attr_extattr.h, interfacing with FreeBSD's extattr support.
Totally untested yet. Might not even compile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27350 a95241bf-73f2-0310-859d-f6bbb57e9c96
* rc uses a global instance of BResources. On destruction it calls Unset() of the BFile member fFile. BNode::Unset then calls close_fd(), which parses the static global DescriptorMap to actually close the descriptor. However on Cygwin the DescriptorMap has been destroyed already for some reason, thus accessing it is invalid. The "fix" is to put the map on the heap and delete it as soon as it gets empty. This way the global BResources instance can be freed without a crash.
* If someone likes to review, feel free to, it didn't cause any issues here
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26585 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cygwin needs some additional defines compared to other platforms
* Additionally stpcpy and strcasestr are unknown on Cygwin. Thus we need to use the one from our posix library.
* ECANCELED is not defined on Cygwin, so only add error in case it is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26584 a95241bf-73f2-0310-859d-f6bbb57e9c96
We now keep track of a lower bound as to when the list should scale
itself back down. When increasing the list size, we double the current,
with the lower bound set to 1/4 of the current size, not allowing it to
go any smaller than the block size. These combined allow us to do very
cheap tests to see if an operation requires a resize at all, and minimize
how often the list actually needs to be resized, since the difference in upper
and lower bounds prevents bouncing back and forth between a size in the case
of adding/removing an item while close to a boundary. All in all this should
make BList noticably more scalable when doing large numbers of add/remove
operations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25946 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch by Vasilis Kaoutsis. I may have cleaned up the file a bit, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25602 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Export a fake _get_port_message_info_etc() for KMessage in libbe_haiku.so
This fixes the build of the app_server test environment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25202 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku code, they work around buggy BeOS code not present on Haiku.
* If this code turns out to be problematic under Haiku (Bruno, did your changes
make any difference at all?), then please fix the problems in the Storage
Kit, don't enable work-arounds for BeOS.
* Simplified the macro check as suggested by Ingo.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24790 a95241bf-73f2-0310-859d-f6bbb57e9c96
if these changes are correct byt they seem to make sense. Ingo?
- Haiku uses the same code that BeOS/Dano/Zeta uses for mime related stuff
during the build process. Added checking for HAIKU_HOST_PLATFORM_HAIKU where
relevant.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24782 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed warnings in Message.cpp and Messenger.cpp when building with GCC 4.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24643 a95241bf-73f2-0310-859d-f6bbb57e9c96
which returns the attribute directory for a given file's stat.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24527 a95241bf-73f2-0310-859d-f6bbb57e9c96
maybe this should be the assembler version we use for x86, but is probably
fine for the purpose of the test environment (only BString uses this)
* Fix semantics of DrawingEngine::CopyToFront() which I recently introduced,
for the fake accelerant of the test environment, we do need to call
Invalidate(), not CopyBackToFront() directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24422 a95241bf-73f2-0310-859d-f6bbb57e9c96
Maybe this needs to be extended to plain R5 as well, but I cannot currently
test that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24210 a95241bf-73f2-0310-859d-f6bbb57e9c96
correct warning) for AbstractPointerListHelper. (libbe_build.so)
* I have had problems with implementing virtual functions inline in the
class declaration before, so I implemented the virtual destructor
externally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24168 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added HaikuBuildCompatibility.h to the src/build/* files that are built as
part of the tools we need to build Haiku.
* Changed HaikuBuildCompatibility.h so that it does not define the things
that are already in the build headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24147 a95241bf-73f2-0310-859d-f6bbb57e9c96
I tested building libroot.so only (BeOS under VMware is not exactly
fun as a build platform), but I think that should suffice.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24134 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers/os version and removed the now duplicate icon type constant
definitions from several sources.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24106 a95241bf-73f2-0310-859d-f6bbb57e9c96
directly onto a device under FreeBSD.
I messed around with the code a little (style-fixes, some refactoring)
without being able to compile or test it, so be careful...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23880 a95241bf-73f2-0310-859d-f6bbb57e9c96
