lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@lucene.com>
Subject Re: File timestamps
Date Tue, 21 Oct 2003 17:48:11 GMT
Maybe I'm misunderstanding your proposal, but the problem is that the 
resolution of file timestamps is not high enough.  On MacOS, HFS files 
only have 1-second resoution, so one can't use a file's timestamp for 
versioning unless one is willing to wait a second when checking the 
version, which slows lots of things down.  So we're forced to either (a) 
use the timestamp to represent a version, rather than a time, or (b) 
implement a version or timestamp of our own, contained in a file. 
Perhaps there are other options...

Doug

Hani Suleiman wrote:
> Adding it inside of a file (segments or otherwise) would mean that the 
> file has to be opened to be read...I might be completely wrong here, but 
> wouldn't it be more efficient to have a separate timestamp file, eg 
> something called segments.[timestamp], with appropriate magic to ensure 
> it's atomically modified etc, and a filter to check for it?
> 
> Doug Cutting wrote:
> 
>> Christoph Goller wrote:
>>
>>> What about living the file timestamps as they are and using
>>> an additional file per index that contains nothing but a counter 
>>> (type long)
>>> which gets incremented everytime the index is changed (SegmentReader and
>>> IndexWriter). I could implement this.
>>
>>
>>
>> I think this is a good idea and would love to see an implementation.  
>> My guess is that you would do something like add a file called 
>> "version" which contains nothing but this long.  Alternately, you 
>> could add the version at the end of the "segments" file or something.  
>> Then all of the IndexReader lastModified methods could be changed to 
>> return the value of the version rather than a date.  For 
>> back-compatibility, the version could in fact be the millisecond time.
>>
>> Is that the sort of thing you're thinking of?
>>
>> Doug
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message