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
a while ago that removed the incorrect automatic addition of Haiku header
directories in case of targets other than "haiku". The app server test
environment does now almost build again. The problem left is related to the
recent changes of the accelerant interface. I suppose someone in the knows
should decide if we can simply use our header or if special handling is
needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22630 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Unfortunately it's not allowed to set user xattrs on symlinks. So, if
we've failed in fs_write_attr() to set an extended attribute, we check
whether the node is a symlink and the attribute just a "BEOS:TYPE",
and pretend to have succeeded in this case. Thus we avoid annoying
error messages e.g. in unzip.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22183 a95241bf-73f2-0310-859d-f6bbb57e9c96
symlinks to be not openable.
* When _kern_open() created a new file, invalid stat data were accessed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22176 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be problematic.
* Changed our xattr attribute namespace to "user.haiku." to prevent
xattrs from other programs (e.g. Beagle) to end up on the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22167 a95241bf-73f2-0310-859d-f6bbb57e9c96
for add-ons/libraries that don't have a signature. I threw our BAppFileInfo
code into libhaikucompat_build.a and link <build>mimeset and
<build>setversion against it, thus overriding the uncooperative BAppFileInfo
implementation in the host platform's libbe. Earlier or later we should use
libbe_build.so on BeOS compatible platforms as well, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21560 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also ported over the new MessageAdapter class
* Removed old BMessage implementation prototypes that apparently were left in the private folder
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21515 a95241bf-73f2-0310-859d-f6bbb57e9c96
-The biggest problem with linking host libraries (libbe_build and libroot_build) was not having the source files compiled with the -fPIC flag. As far as I can tell, we want to do this on all of the other host platforms as well, so hacked the jam files a bit to add it.
Forgive me if I've committed more Jamfile sins.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21423 a95241bf-73f2-0310-859d-f6bbb57e9c96
-fs_shell was using weak aliases, which is apparently not supported on the darwin toolchain
(or it's supported in some different way)
-remove building strl* routines for some of the host tools, since that already exists in libSystem
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21407 a95241bf-73f2-0310-859d-f6bbb57e9c96
xattrs. It can be enabled with the configure switch "--use-xattr". Note
that the amount of data stored in attributes may be limited by the used
file system -- e.g. AFAIK ext3 has a limit of one block (usually 4 KB)
for all attributes of a file, which might not suffice. XFS should be
fine, as should ReiserFS 3.6 (or any FS which stores attributes in
hidden files).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20609 a95241bf-73f2-0310-859d-f6bbb57e9c96
overwrite them with the host platform errno again. We do now track
changes and use a hopefully reasonable strategy for updating the host
errno.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20608 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reorganized sources a bit:
- The descriptor support is in a separate file now.
- Disentangled the attribute support from the other stuff.
* Removed broken xattr use for attribute support.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20606 a95241bf-73f2-0310-859d-f6bbb57e9c96
again for target libbe_test. Added respective syscall stubs and other functions
to libhaikucompat.a.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20447 a95241bf-73f2-0310-859d-f6bbb57e9c96
It's hopefully now used everywhere instead of B_RAW_TYPE where appropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19219 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Furthermore, this call crashes when called with a NULL version info
* Fixed some typos that should have proven problematic under R5/BONE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19205 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_NAME_NOT_FOUND instead of B_ENTRY_NOT_FOUND for all missing types).
* Also, BMimeType::GuessMimeType() doesn't seem to work at all under BeOS.
* The build's MIME updater no longer ignores the error from DoMimeUpdate() - so that
you'll now may get error messages during the build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19202 a95241bf-73f2-0310-859d-f6bbb57e9c96
A consequence is the FileType tracker addon (which hasn't a signature) has now its attributes set on Linux builds
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17642 a95241bf-73f2-0310-859d-f6bbb57e9c96
of an object file, if the file's resources didn't specify supported
types. Both under Haiku itself and for the Linux build. This finally closes
bug 170 (AboutHaiku not being startable from Deskbar when built under
Linux).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17354 a95241bf-73f2-0310-859d-f6bbb57e9c96
read from (and the system version_info missing) GetVersionInfo() always
failed. Given that rc only writes the app version_info, mimeset never
created a BEOS:APP_VERSION attribute (nor ones for supported types icons).
The version attribute was usually created nevertheless, as a side effect
of the subsequent setversion invocation.
Under Linux the attribute emulation can accidentially pick up the
attributes of an earlier deleted node that had the the same node ID as the
file in question, which in this case could cause an invalid
BEOS:APP_VERSION attribute (the app version_info part at least).
Now GetVersionInfo() doesn't fail anymore, when only one info could be
read (the other one is zeroed). Not sure, if that is what BeOS does, but
it shouldn't harm. This fixes bug #100.
Also made SetVersionInfo() zero out what couldn't be read before writing it
back.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16320 a95241bf-73f2-0310-859d-f6bbb57e9c96
build platforms a bit. Generally extended attributes seem to be
supported up to a very limited size per node, thus a one-to-one
mapping isn't a good idea, but I figured, they could at least
help to recognize when and attribute directory doesn't belong to
a node (in case the original node had been removed and the a new
one created with the same node ID).
The implementation should ensure that, but I can't really test
it, since ReiserFS 3.6 under my SuSE Linux 9.2 installation
apparently doesn't support extended attributes. So it's disabled
for the time being.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16228 a95241bf-73f2-0310-859d-f6bbb57e9c96
Sorry, that was the problem actually reported by Alexander Deynichenko...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16216 a95241bf-73f2-0310-859d-f6bbb57e9c96
