Thanks to everyone who commented. Clearly, I have a lot to think about, but thanks for the help.
Scott -----Original Message----- From: Rob Staveley (Tom) [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 2:53 PM To: java-user@lucene.apache.org Subject: RE: Managing a large archival (and constantly changing) database Aha, OK that makes sense. Likewise James Pine's explanation. Thanks both of you. -----Original Message----- From: Chris Hostetter [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
