[haiku-commits] Re: r33744 - haiku/trunk/src/kits/tracker
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 23 Oct 2009 16:54:17 +0200
alex@xxxxxxxxxxxx wrote:
> + if (model->InitCheck() == B_ENTRY_NOT_FOUND) {
> + // might happen if the file was deleted shortly after
> creation and we
> + // were too busy to create the model in time see #4130
> + delete model;
> + return NULL;
> + } else if (model->InitCheck() != B_OK) {
I thought about this again, and since this happens with queries as
well, I don't think this is the right way to handle this problem, or
else query results are lost.
AFAICT, with mails the problem is that they are first saved to a
temporary file, and then renamed. When Tracker is too late picking up
the query update, the file will already have been renamed at that time
(ie. the above B_ENTRY_NOT_FOUND would happen, even though the file
still exists), so it won't show it anymore.
This problem was actually hidden by the query code (that I recently
changed) sent remove/add notifications on rename. Maybe that wasn't
such a bad idea after all, as it would fix this problem as long as the
parent directory is updated as well at the same time (which it actually
is, I just checked).
In other words, since the node monitoring/query mechanism works
asynchronously, queries are spread out all over the file system, and we
have no way of tracking all file system activities yet, there is an
inherent race condition that might not be so easy to fix (other than
changing the BQuery code back again).
What happens with the zombie models? In theory, since the inode number
is known, Tracker might be able to resolve those, but it wouldn't
exactly be a cheap operation.
Ideas welcome.
Bye,
Axel.
Other related posts:
