[Namazu-users-en] Re: cfile_mtime in line 1852

Tadamasa Teranishi yw3t-trns at asahi-net.or.jp
Thu Jun 16 14:21:32 JST 2005

Bhaskar wrote:
> i could find that the file is not available for further processing.
> Please find more details about the scenario.

mknmz doesn't assume the filename is changed while executing it. 

If only this kind of file is handled, correspondence might be 
possible by customizing. 

The one that there are "S" and "SR" in the end of the file name 
removes it and makes the file list. 
When accessing the file, it accesses it by the file name with 
"SR" first. 
It accesses it by the file name with "S" if making an error. 
Still, if it is an error, it accesses it by an untouched filename. 
Such processing will only have to be applied to the place where 
open() and stat() are done.
However, the customizing will become serious work. 

As another easy method. 
Line number 1845 of mknmz is rewritten. 

        if (defined($rdocs_ref->{'deleted'}{$cfile})) {

        if (!-f $cfile || defined($rdocs_ref->{'deleted'}{$cfile})) {

In this case, it is likely to be reflected in next mknmz though 
the file of the problem is not reflected in the index. 
Moreover, $cfile_mtime has the possibility of becoming undefined 
though it decreases according to timing than before. 

> >According to circumstances, the index might be destroyed.

The possibility of destroying other parts of the index might be 
low though information on the file might break if the reason 
why $cfile_mtime becomes undefined is a change in the filename 
executing mknmz. 

The uncorrection might not become a major issue either. 
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E

More information about the Namazu-users-en mailing list