lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernhard Messer <>
Subject Re: strange behaviour in CompoundFileReader fileModified and touchFile
Date Fri, 01 Oct 2004 15:14:51 GMT

> Bernhard Messer wrote:
>> hi,
>> CompoundFileReader class contains some code where i can't follow the 
>> idea behind it. Maybe somebody else can switch on the light for me, 
>> so i can see the track. There are 2 public methods which definitly 
>> don't work as expected. I know, extending Directory forces one to 
>> implement the methods,  but in that particular, case the 
>> implementation is just confusing me and my be other people too.
>>    public long fileModified(String name) throws IOException {
>>        return directory.fileModified(fileName);
>>    }
>>    public void touchFile(String name) throws IOException {
>>        directory.touchFile(fileName);
>>    }
>> Looking at the implementation, both methods are working on the 
>> compound filename itself, regardless what the filename passed in has 
>> as it's value. It would be much more understandable, if these methods 
>> throw some UnsupportedOperationException. The other way is to to 
>> change them in a way, that the underlaying directory method calls 
>> will get the real filename passed in and not the compound filename 
>> itself.
> Well, the reason I did it this way is because I thought this would be 
> the least amount of disruption to the programs out there that might be 
> using these APIs. You can't really pass the "name" into the directory 
> since it doesn't know about these as individual files. Directoy only 
> knows about the compound file.

I'm not sure if this is correct. Looking at the implementation for 
example in FSDirectory, every file, doesn't matter if it is related to 
Lucene or not can be touched.

> To implement the fileModified() fully, you could just store timestamps 
> in the file, but then they would just the same as the timestamp on the 
> overall file, unless there was also touchFile() support.To implement 
> touch file, you'd have to open the file in random access and update 
> the timestamp field of an individual file. This can certainly be done, 
> but I didn't have a need for it. You could throw the Unsupported 
> exception, but this could make callers have to change. Anyway, the 
> compromise I chose was to treat a "touch" on one file as if a "touch" 
> on all files for the segment. This works in most usages. The only time 
> this would be a problem is if you implemented some kind of timestamp 
> set/check that would depend on files in a segment having different 
> timestamps. This might be important for updating segments, but since 
> this is never done, I'm not sure this is really that useful. Do you 
> have case in mind when this is proving to be a limitation?
Agree with you. I don't see the need for a full implementation of touch 
file and lastModified for the internal used compound file parts or any 
other file. But the way it is implemented now, it just does something 
different than it looks for the user of the API. The idea i had in mind, 
was to implement it in a way that the compound file can be touched and 
lastModified can be read also. If the user passes in a  filename, 
different to the compound file name, either an 
UnsupportedOperationException or even better an IOException could be thrown.

what do you think ?


>> just a thought ;-)
>> bernhard
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message