lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hani Suleiman <h...@formicary.net>
Subject Re: File timestamps
Date Tue, 21 Oct 2003 17:55:10 GMT
Sorry, I should have been clearer, I meant using a file, but putting 
System.currentTimeMillis() in the filename (or any equivelant versioning 
number, really), rather than in the file data.

Doug Cutting wrote:
> 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
> 
> 



---------------------------------------------------------------------
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