[Dirvish] summary file fun?

[Dave Howorth]

Jason Boxman wrote:
> I don't know that I have permission to reproduce the sender, but in a
> private mail someone found the problem below with `dirvish-expire`.  Anyone
> else experience this?
> 
>>But unfortunately the dirvish-expire didn't work.
>>Nothing happend, no version ever had been deleted.
>>
>>So I had a look into the code and finally found the problem.
>>
>>The subroutine findop reacts upon files called "summary" and expects to
>>find there information about the expire time.
>>
>>But we use Ximian Evolution and there are files named "summary"
>>somewhere in the depths of the ~/evolution directory.
>>
>>Exactly: evolution/mail/imap/USERNAME at DOMAINNAME/INBOX/summary.
>>
>>
>>So I think I have to call this a bug! Just to search for a file called
>>"summary" isn't enough - as I had to experience.
>>
>>I changed the line
>>
>>  if ($_ eq 'summary')
>>
>>into
>>
>>  if (($_ eq 'summary') && not ($File::Find::dir =~ /@mail/))
>>
>>and everything was OK. Obviously there were no other files or
>>directories called "summary" in our backup.
>>But this is not really a solution! What do you suggest?!?

This sounds more likely to be a configuration error to me. The start of 
findop is:

sub findop
{
         if ($_ eq 'tree')
         {
                 $File::Find::prune = 1;
                 return 0;
         }
         if ($_ eq 'summary')
         {

findop is used as the 'wanted' function by File::Find and that prune 
setting at the top means that it should never descend into the actual 
data when searching for the control information in the summary file.

It appears that for some reason, it *is* descending into the data tree, 
so my best guess is a configuration issue. I have this file:

   ./downloads/gen-sw/mysql/mysql-cookbook/recipes/summary

in my home directory and it hasn't caused me any problem.

Cheers, Dave