<Anarchos>
Begasus[m] i found a workaround : "df" displays the devices and where they are mounted
<nephele>
phschafft: around?
<Begasus[m]>
'lo nephele
<scanty>
Begasus[m]: cool screenshot. What is that animal there, a lizard, or a dragon?
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
correct Anarchos :)
<phschafft>
a little bit.
<scanty>
or neither
<Begasus[m]>
KDE mascot :)
<scanty>
or both at the same time, until we make an observation.
<scanty>
ah cool.
<Begasus[m]>
k, food is ready, time to close down :)
<Begasus[m]>
cu peeps!
<scanty>
bye Begasus[m], have a pleasant day
HaikuUser has joined #haiku
<nephele>
phschafft: I wanted to ask you, what could be a good way to eliminate the need to "scan" a disk to see how full folders are for a desktop OS?
<PulkoMandy>
Stop doing folders?
<nephele>
PulkoMandy: care to elaborate?
<PulkoMandy>
Or store some data in directory entries about this, which would mean whenever you create, or delete, or resize a file, you need to update all its parent directories
<PulkoMandy>
Which there is no easy way to find: because of hardlinks, and because the file doesn't have a pointer to its parent directory
<phschafft>
which must be a defined and known set.
<phschafft>
exactly.
<phschafft>
I mean you could get close to it by doing a cache, but that is just that, a cache.
<PulkoMandy>
So, now you do a ot of work at every file change, instead of doing it very rarely when someone actually needs that info
<nephele>
Well, maybe there is another way to aproach the probem. Most of this is for the use case of disk analyzer where users mostly just want to know why the disk is as full as it is
<PulkoMandy>
Yes, so do a scan at that time. Happens maybe once a year or so and you don't need the data at other times
<PulkoMandy>
So it's not worth maintaining it
<phschafft>
PulkoMandy: yes.
<nephele>
I don't like waiting on a computer for long times for such maintenance tasks *shrug*
<nephele>
But maybe that really is the crux then, that the folder metaphore doesn't quite work
<phschafft>
directories are just not the way to go.
<PulkoMandy>
You can query all files and sort by size (or maybe query files larger than some size)
<phschafft>
and I would guess that a lot of time is actually spend by the recursion part of the walk.
<nephele>
for packagefs this same case is already much easier, i can check how big the package files are instead of looking at how their virtual layout looks
<PulkoMandy>
But my experience with that is, when you need to cleanup, at least in my disks, it's usually a lot of small files and not a few big ones
<phschafft>
vs. a flat structure (such as an index).
<nephele>
PulkoMandy: yes, but then you are back to "scan the disk" and you still need to know the context of what the files are even in
<PulkoMandy>
So aggregating the files in some way is needed. And directories is a metaphor I understand reasonably well when deciding if I still need something or not
<PulkoMandy>
Yes, that's my point, you need to scan the disk not to find large files, but to find their context
<phschafft>
directories for the good and the bad. but as long as you have them you need this kind of walk.
<nephele>
Can we add some more context in other ways? packagefs is a kind of context for example... in the same vain some context for application specific files could be nice.
<phschafft>
and my guess would be that you can shave off a few percent by optimising the filesystem interaction.
<PulkoMandy>
Maybe just make diskusage show some partial results in realtime. If you make a somewhat nice vizualization, the waiting becomes fun!
<nephele>
I guess like how plan9 has per application views
<nephele>
i hate bussy cursors :D
<phschafft>
like to not read one entry from the directory and do a stat() but do it in batches.
<phschafft>
or use statat().
<PulkoMandy>
nephele: I was thinking more like old disk defragmenters, showing how they move things around on disk
<nephele>
phschafft: haiku is already *really* slow when dealing with lots of small files it seems.... event he installer app which is usually so fast replicating a system becomes nigh unusable when copying git repos
<PulkoMandy>
Much better to watch than a busy cursor or even a progress bar
<nephele>
PulkoMandy: like having partial results of what was already walked?
duncsauce has joined #haiku
<phschafft>
PulkoMandy++
<nephele>
i guess if it's not "jumping" around too much that could be cool indeed
<phschafft>
nephele: your most hated Linux also has per thread views ;)
<nephele>
I don't hate linux
AndrevS has joined #haiku
<phschafft>
so maybe you want to check the source code of that tool you are using to see if it uses stat() in batches or if it uses statat().
<nephele>
phschafft: i was also thinking of android, and nowadays with unveil OpenBSD also has something like that (though that is more ephermal)
<phschafft>
altering that pattern might improve things (a lot).
<nephele>
It uses neither directly phschafft
<nephele>
Though, if you need to scan the disk to find out how big stuff is maybe that would even be done more directly with a call that asks the filesystem to perform this task, and then get results in batches once they come in
<phschafft>
which would make the filesystem API more complicated.
<nephele>
Well, it would be one additional call you don't have to implement, so yes, maybe a bit. but not too much
<phschafft>
I just say that you should keep gain and costs balanced.
<nekobot>
• OscarL (a6bff527): _python* packages: do not use Python 3.9 as "defaultVersion" anymore. (#12589)…
<Anarchos>
Begasus[m] i finally managed to tranfer my folders with wget
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #haiku
Aedil has quit [Quit: leaving]
<Anarchos>
is there a way to attach a given thread to current Terminal ?
<Anarchos>
i lost my ssh session in which i launched 'wget'. I can reconnect to ssh but now i just see wget is still running but i have no logs anymore
<Habbie>
on linux there is "reptyr"
<Habbie>
but i don't see it in haikuports
<Habbie>
oh, is the ssh to a linux machine?
<Anarchos>
Habbie no, betweent two haiku machines
<Habbie>
ok right
<Habbie>
then -my- only idea is to see if you can port reptyr
<nephele>
BSD has a "watch" command for this iirc
<Habbie>
it assumes there is a tty attached at all though, i think
<Habbie>
it also relies on a specific kernel driver, snp (for 'snoop')
<Anarchos>
no trouble, i will just wait until this process disappear from the «ps» output
nephele has quit [Quit: Vision[]: i've been blurred!]
jmairboeck has joined #haiku
Aedil has joined #haiku
BrunoSpr has quit [Quit: Vision[]: Ich wurde eingeweicht!]
<Anarchos>
oh there is no thumbnail in Tracker for a x-vnd.haiku-icon file :)
<Anarchos>
what a shame !
<scanty>
help!
<scanty>
my trash has disappeared
<scanty>
i may have dragged it offscreen by accident.
<scanty>
oh whoops
<scanty>
it was hiding.
<scanty>
nvm i'm foolish.
<Anarchos>
scanty did you find it again ?
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
<scanty>
Anarchos: yes, sorry for the delay, was coding on the other desktop
<Anarchos>
scanty no trouble, i am on holidays :)
<scanty>
oh how nice.
<scanty>
did you go anywhere, or are you just staying home and taking it easy
<Anarchos>
scanty not nice to spend holydays alone