<Skipp_OSX>
alright now onto find window hanging bug
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
deneel has quit [Remote host closed the connection]
deneel has joined #haiku
chilledfrogs has quit [Ping timeout: 480 seconds]
<phschafft>
mau.
<coolcoder613>
Hello
* phschafft
waves to coolcoder613.
<phschafft>
I was wondering if a user wants to save some data to some filesystem or directory without providing a name how to come up with some file name (for filesystems that require a filename like... virtually all).
<phschafft>
I guess the best would be to go with an algo similar as to how tempfiles are generated: some pattern plus a bit of random, if already exists retry.
<Skipp_OSX>
ok, much easier to reproduce the bug with 1 processor
SLema has quit [Quit: Vision[]: i've been blurred!]
<phschafft>
Does Haiku support any of O_EXEC, O_SEARCH, or O_PATH?
<Begasus>
vaguely remember the names :)
<phschafft>
basically opening a file for holding a handle, but not for doing any io on it.
<phschafft>
it is commonly used with f*() and *at().
<dovsienko>
if it is in POSIX, then likely yes
<dovsienko>
that said, neither of the above appear in the Haiku source code repository
<dovsienko>
phschafft: would you like to contribute a patch to add such support?
<phschafft>
O_EXEC, and O_SEARCH is, O_PATH is Linux (and some others also implemented it).
<phschafft>
for compatibility they can often be aliased to O_RDONLY.
<phschafft>
even if they're made into actual distinct (non-zero, non-overlapping) flags the kernel may still just alias them to O_RDONLY which would be very simple change, allow compatibility, and later on actually treating them differently.
<phschafft>
I think Linux just aliases them all to O_PATH, using only one bit.
<phschafft>
POSIX comments: (note that it is unspecified whether O_EXEC and O_SEARCH have the same value)
Anarchos has joined #haiku
<dovsienko>
the open(3P) man page Haiku has describes both O_EXEC and O_PATH
<phschafft>
how come if you said they're not to be found in the source?
<dovsienko>
that's from the man_pages_posix package, which comes from the POSIX standard, not the Haiku base system
<dovsienko>
before a proper fix is in place, it may be a good idea to patch the man page to mention these flags in the PROLOG section
<dovsienko>
the standard boilerplate is currently "This manual page is part of the POSIX Programmer's Manual. This interface might not be implemented on Haiku."
<dovsienko>
that's what I sometimes do with bugs that are not going to be fixed anytime soon: document them
* phschafft
nods.
<phschafft>
I think I would like to try some combinations of flags to see how open() actually reacts to them.
<phschafft>
again, maybe it can be fixed by just aliasing some constants for now. (which should still go with at least a note in the manual.)
mmu_man has joined #haiku
Begasus has quit [Quit: Vision[]: i've been blurred!]
Begasus has joined #haiku
Begasus has quit [Read error: Connection reset by peer]
Begasus has joined #haiku
Begasus has quit []
Begasus has joined #haiku
<Begasus>
k, back on par (hrev) :)
Anarchos has quit [Ping timeout: 480 seconds]
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
Habbie has joined #haiku
<phschafft>
:)
<Begasus>
k, buildmasters updated also? upload package haiku-r1~beta5_hrev57937_111-1-x86_64.hpkg to builder
<nekobot>
[haiku/haiku] 6533131daf19 - posix: dladdr was introduced in POSIX-2024, but with Dl_info_t
<phschafft>
Linux allows both removing and adding data blocks at any position as long as everything is block alogned.
<phschafft>
*aligned
<phschafft>
allowing to prepend at any size surely comes with the problem of having a subblock gap.
<dovsienko>
never heard of it, what's the function that does it?
<phschafft>
fallocate(2)
<phschafft>
there is also a command line tool for it.
<phschafft>
it can do a wide range of operations that basically operate on block allocation one way or another.
nephele_xmpp has joined #haiku
<dovsienko>
phschafft: thanks
<dovsienko>
does anybody recognise this header? fatal error: X11/Intrinsic.h: No such file or directory
<dovsienko>
(libx11_devel is installed)
yann64 has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
I see it's in /boot/system/develop/headers/X11
<Begasus>
dovsienko, installed libxt_devel?
<dovsienko>
Begasus: thanks, that helped
<Begasus>
np :)
<dovsienko>
fatal error: Xm/XmAll.h: No such file or directory
<dovsienko>
that's Lesstif/Motif. I presume these were too difficult to port, otherwise somebody would have already done it
mmu_man has joined #haiku
Anarchos has joined #haiku
<dovsienko>
phschafft: so, there's posix_fallocate()
<dovsienko>
but what you want is the Linux-specific fallocate(2)
linuxmaster has quit [Ping timeout: 480 seconds]
<phschafft>
dovsienko: correct. posix_fallocate() is a subset of that.
mmu_man has quit [Ping timeout: 480 seconds]
<phschafft>
I'm happy it's there. however I feel like it was designed in a way that... will make it of limited use and is hard to overcome.
<phschafft>
at least they should have added a flags parameter.
<phschafft>
most importantly for me posix_fallocate() doesn't support background operation.
<dovsienko>
well, then you call it from a separate thread and wait for the completion if necessary, right?
nephele_xmpp has left #haiku [Error from remote client]
<phschafft>
you can do that. but it would require to have such a thread and/or start it.
<phschafft>
which opens a middle ground where waiting for it takes time, and starting a thread is not yet worth it.
<phschafft>
(keep in mind that depending on how much you allocate and what your current fragmentation is, which fs you use, ... the time it requires to complete can change a lot and might not be very predictable)
<phschafft>
however I think it is safe to assume that writing N byte followed by a fdatasync() will take no shorter than calling posix_fallocate() with the same amount of N.
<phschafft>
and you can still fragment your calls. e.g. calling for a tenth of your total length, then writing that, then calling for the next tenth, writinge that, ....
<botifico>
[haikuports/haikuports] Begasus a30b856 - wxqt, revbump for libtiff6 (#11099)
<Begasus>
Hi humdinger :)
<humdinger>
Begasus: Am I correct that currently submitted haikuports recipes will only be in effect for nightly users and when beta5 hits?
<humdinger>
as beta4 repos are down
<Begasus>
beta4 repos have been down for quite a while already humdinger
<Begasus>
beta5 repos are up and in use afaik
Skipp_OSX has quit [Ping timeout: 480 seconds]
<Begasus>
at least updates work here
<humdinger>
I know. I mean, if I release an app that depends on beta5 feaures, it's save to do now, right?
<Begasus>
yeah, I could install it as I have the r1beta repo setup
<Begasus>
just not for r1beta4 :)
<Begasus>
but then again, I don't have the usual setup installed also :P
<Begasus>
must be nuts ... building grpc ...
<humdinger>
OK. I'll update QuickLaunch then, so new users of beta5 won't have a chance to install the old version.
<humdinger>
I feel the beta5 release is imminent now. :)
<Begasus>
will it be included in the release?
<humdinger>
no. :)
<Begasus>
yeah, most is up and running fine, just some issues with github/gitlab on the browsers
<humdinger>
too bad there are still some translations missing, but well...
<Begasus>
for the smaller ones Dutch should be fine, didn't tackle the large/hard ones
<humdinger>
I meant just for QuickLaunch. You finished Dutch there, thanks!
<Begasus>
np, keeping up with small changes isn't that hard :)
<Begasus>
gave Vision a look ... (and some of the others) ... but not yet for me :)
<humdinger>
Most Dutch people speak English anyway :)
freddietilley has quit [Quit: WeeChat 4.2.2]
<Begasus>
right, those don't bother me, and if anyone has issues they are free to help out :)
mmu_man has quit [Ping timeout: 480 seconds]
<Begasus>
5K objects to go ...
Skipp_OSX has joined #haiku
<waddlesplash>
dovsienko: Motif is very demanding and doesn't work properly on Xlibe, yes. I have tested it before, but didn't spend the time trying to fix it
_-Caleb-_ has left #haiku [#haiku]
<waddlesplash>
I can't remember if I tried Lesstif and if it was any better
<Begasus>
maybe I should just push it to the buildmasters :) boot/system/lib/libabsl_time_zone.so.2301.0.0 /packages/openssl3-3.0.14-2/.self/develop/lib/libssl.so /packages/openssl3-3.0.14-2/.self/develop/lib/libcrypto.so && :
<waddlesplash>
Xt doesn't quite work either but that one at least isn't so far off from working and could probably be fixed with some work. There is an open ticket at Xlibe about that where I note what it needs
<Begasus>
those don't get regular updates ... luckaly :D
mmu_man has quit [Ping timeout: 480 seconds]
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
<waddlesplash>
Skipp_OSX: any luck with that Tracker queries fix?
mmu_man has joined #haiku
<Skipp_OSX>
I thought I had it... but now I can't reproduce so it's tricky
<Skipp_OSX>
short answer, no...
<Skipp_OSX>
I found that with one cpu core active it is much easier to reproduce the bug. I thought maybe it was lock contention with the window list causing the problem... but unfortunately no that's not it.
<waddlesplash>
the file isn't geting deleted
<waddlesplash>
at least that's what I was seeing, the window isn't closed because the query file was never deleted so of course we never get a node monitor notification
<waddlesplash>
so, why isn't it getting deleted?
<humdinger>
BTW, recent changes did away with the "temporary queries". those should self-destruct after 2 weeks, I think. But I don't think that worked for quite some time before the feature was removed.
<humdinger>
maybe related.
<Skipp_OSX>
Well I can tell you that entry.Remove() is succeeding B_OK, so there's no B_BUSY from locking going on there.
AD_Haiku_onPC has joined #haiku
<Skipp_OSX>
but then why isn't the BPoseView node monitoring picking that up? no clue... for me the problem is different because the file is getting deleted, but the window isn't closing.
<Skipp_OSX>
It definitely seems like a locking thing that it's waiting on a lock to be freed that never does and then times out but why? There shouldn't be lock contention or there isn't afaik.
AD_Haiku_onPC_ has quit [Ping timeout: 480 seconds]
* humdinger
waves
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
Coldfirex has quit [Remote host closed the connection]
bjork1intosh has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
nipos has left #haiku [Disconnected: Replaced by new connection]
nipos has joined #haiku
mmu_man has joined #haiku
<coolcoder613>
Hi erysdren
<phschafft>
the flags of open() are an int.
<phschafft>
and:
<phschafft>
#define O_DIRECTORY 0x00200000 /* fail if not a directory */
<phschafft>
seems to be the highest defined flag.
<phschafft>
which also suggests that this int is to be understood as to have at least 31 useful bits.
<phschafft>
so while it's tight there seems to be room for O_EXEC, O_SEARCH, and O_PATH. also keeping in mind that they can share the same bit (as specifically allowed by POSIX).
<phschafft>
also O_RDONLY is defined in the classic way as zero (while POSIX suggests it to be non-zero but permits for it to be zero).
<erysdren>
hi oolcoder613, hows it going
<erysdren>
*coolcoder613
<waddlesplash>
phschafft: O_PATH is similar to our O_NOFOLLOW
<waddlesplash>
O_NOFOLLOW allows you to open() a symlink
<waddlesplash>
can't remember if the semantics are similar or actually identical
<phschafft>
posix tells us:
<phschafft>
If path names a symbolic link, fail and set errno to [ELOOP].
<phschafft>
so if it allows opening a symlink that would be in conflict.
<phschafft>
will test that after I did my current test and we'll see.
<phschafft>
ok, if I set O_RDONLY|x with x being some not yet defined bit open succeeds on a normal file.
<phschafft>
seems it fails on a symlink as per POSIX.
<phschafft>
the Linux manpage also notes:
<phschafft>
When O_PATH is specified in flags, flag bits other than O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW are ignored.
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Coldfirex has joined #haiku
<phschafft>
that said, time for some rest. wil dig in the code some more tomorrow.
<coolcoder613>
erysdren: I'm well, I've been playing Minecraft quite a bit,