[haiku-gsoc] Re: Disk Queries Return Unpredictabe Results
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 22 Jul 2009 22:38:49 +0200 CEST
Ankur Sethi <get.me.ankur@xxxxxxxxx> wrote:
> Something seems to be wrong with disk queries on my Haiku build.
> Running
> the following returns *all* files on my disk:
>
> > query -a "last_modified > %now%"
>
> I'm fairly certain that none of the files on my disk are from the
> future. Running something like this also returns all files:
>
> > query -a "last_modified > 7/23/2030"
I noticed something like this a while back, too, but never got around (
= forgot) to look into it.
I'll take a look tomorrow.
> Since indexing every file on disk was taking a long time, I changed
> my
> query to "name = *.txt" for debugging purposes. Then I noticed that a
> couple of files were showing up repeatedly in the live query. The
> indexer was indexing the same files endlessly.
That at least should really never happen, and deserves to get
investigated. Your index might be damaged.
> I have three BFS volumes on my PC. chekfs runs on two of them without
> any hiccups. Running chekfs on the third volume, however, drops me
> into
> the kernel debugger. (Note that there are no files matching "name =
> *.txt" on the third volume).
>
> What could be the problem here? A bug in the filesystem code or a
> disk
> corruption?
Without giving any hint to what KDL message you saw, I can't even
guess.
In any case, even with disk corruption (very likely), BFS nor checkfs
should ever crash; the code must be robust enough to deal with
corruption.
> NOTE: I still haven't tested the Beacon code in a VMWare image. I'll
> do
> that and see if something similar happens in the VM or not.
Real hardware is what counts, anyway.
Bye,
Axel.
Other related posts:
