Re: [PATCH] Fix trash deep count

[Martin Wehner <martin wehner gmail com>]

On Tue, 2005-08-02 at 00:19 +0200, Christian Neumair wrote: 
> Am Montag, den 01.08.2005, 22:33 +0200 schrieb Martin Wehner:
> > This doesn't quite work though: The deep-count request is set to
> > REQUEST_DONE on the first pass through (and all values set to 0), so it
> > won't try to count again on the second pass (with the known filetype).
> 
> If no MIME type is ready, any_file_was_ready is FALSE and status set to
> NAUTILUS_REQUEST_NOT_STARTED. If some of them (but not all) are ready,
> the status is set to NAUTILUS_REQUEST_IN_PROGRESS.

Yes, but I was talking about deep_count_start not
trash_file_get_deep_counts. Sorry, I probably should have mentioned
that :)

> There is not just one "the file type", there are multiple ones, one for
> each trash directory, some of which can be remote system. The trick is
> really that as soon as these attributes are ready for any of our trash
> directories, we ask the property window to re-read the trash count (cf.
> file_type_is_ready).

I understand the intention of the patch and the concept of the trash
having multiple backing directories, but it doesn't work - I actually
tried it (It shows a deep count in the properties, but the count is off
if you have stuff in one of the affected trash directories).
deep_count_start will return 0s because the file is marked as no longer
being needy for a deep count, so it won't count again. You'd have to
invalidate the deep count before re-reading it.

> > I'm not sure it's the
> > right fix though, it seems to be a systematic problem (it also applies
> > to the mime_list and directory_count requests) - There seems to be no
> > guarantee that you got the file type at this point, which will make
> > these functions bail out.
> 
> Hrm haven't even thought about these. Any other ideas than adding
> similar call_when_ready code to the relevant functions?

No, not without digging deeper into the code.

Martin