No, it doesn’t, that’s what the cache is for… most likely the file you want to access is already in RAM and there’s not even a need to access any package at all. But the filesystem already keeps the final directory structure in RAM as well.
Yes, but BFS predates that, and no other filesystem implements typed and queryable extended attributes so we’re kind of stuck with that.
We could make a BeOS compatibility package that creates these links. Might open up many old apps for us.
You can already enable the BeOSCompatibility optional package if you compile Haiku yourself. It will create a few links in /boot/beos and /boot/var.
Do you have a list of apps that require these? It is not enabled by default because we have not found a lot of things that need these.
You didn’t read the whole thing, the point is if you limited cache size (either artificial limitation or low ram) it would force it to redecompress all the time… but whatever.
Is this something that is already done on 32-bit Haiku?
As I wrote in the post you are quoting, no, it is not currently enabled, and we have not found apps that need it, or the apps have long since been fixed.
(this does not mean there are no such apps, let us know if you find some)
I don’t have a specific use case in mind, I was just adding to the conversation. But it does seem odd to me that BeCompatible (good name for it 
would require the user to compile from source. This is the possibly first time many ppl are hearing about this option. Maybe there should be a hpkg option as well.
Well, I don’t see much use in providing legacy support for things that are not used by any applications. This was developped sometime before the package management system, when /boot/beos was renamed to /boot/system and a few things shuffled around to avoid having a /boot/system/system.
In the end it turns out a lot of applications are packaged in .pkg files (we have an installer for these that automatically rewrites the paths to put things in the right place), and use find_directory (which will usually do the right thing as well). So, this thing was done, but it was not super useful and it was left disabled.
I see. 32 bit Haiku is compatible with BeOS apps. Is it only compatible with them if you enable it, or it’s for certain applications that may give trouble.
Most applications don’t hardcode any paths at all (the normal way to install a BeOS app is “unzip it wherever you want, done”).
So, yes, a small, possibly empty set of applications may require these symlinks because they hardcoded a path to some file inside /boot/beos. Again, does anyone have an exemple of such an app? Because for me it isn’t very interesting to discuss hypothetical issues that don’t affect any known application.
I see. Well that’s good to know. Thanks. I guess I’ve run BeOS apps in Haiku without enabling any compatibility, but it’s been a while so I wasn’t certain.
I remember those days. You ended up with a dozen almost-identical copies of libSDL.so and such. Package management is the way to go!
Pretty sure several developers have mentioned this as a miss step anyway, that could be fixed at the API level eg attributes should be in a normal database, rather than melding the DB and the FS. That way the BeAPI could be portable over different FS types rather than relying on BFS.
As it is right now Haiku is doubling down on making this same mistake with packagefs… merging packages with the FS. sigh.