lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Staveley (Tom)" <rstave...@seseit.com>
Subject RE: Managing a large archival (and constantly changing) database
Date Fri, 07 Jul 2006 20:52:38 GMT
Aha, OK that makes sense. Likewise James Pine's explanation. Thanks both of
you.

-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org] 
Sent: 07 July 2006 20:40
To: java-user@lucene.apache.org
Subject: RE: Managing a large archival (and constantly changing) database


: How can that be so? When the segments file is re-written it will surely
: clobber the copy rather than creating a new INODE, because it has the same
: name... wouldn't it?

if you take a look at SegmentInfos.java you'll see that an existing segments
file is never modified.  a new segments file is created (named creatively
"segments.new" and once it is complete, it is renamed "segments" in the
index directory (so the old inode is completley unmodified and still
accessible from the cloned directory)

: 	echo update > x/x.txt

i believe what is happening is analogous to...

        echo update > x/x.new
        mv x/x.new x/x.txt


-Hoss


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

Mime
View raw message