Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Tatu Saloranta <tatu@hypermall.net>
Reply-To: tatu@hypermall.net
Organization: Linux-users missalie
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Subject: Re: FSDirectory patch for file renaming
Date: Tue, 18 Feb 2003 20:54:30 -0700
User-Agent: KMail/1.4.3
References: <20030217201833.3529.qmail@web12701.mail.yahoo.com>
In-Reply-To: <20030217201833.3529.qmail@web12701.mail.yahoo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200302182054.30942.tatu@hypermall.net>

This may be getting bit off-topic, but since I'm currently using renameTo() on 
a project, I was wondering what are exact conditions under which people have 
seen this problem (I got the impression it's much more common on certain 
platforms etc?).
So is true that the problem mostly (only?) occurs  when following conditions 
are met:

(a) A file with name renameTo() would rename another file existed earlier
(b) 'Old' file is deleted
(c) renameTo() tries to rename new file to 'old' file name, and native file 
system for some reason still thinks that file exists?

or are there other cases where same problem occurs? And also, is this more 
frequent on Windows platform? (I haven't seen this on Solaris or Linux, but I 
haven't had to use renameTo() heavily).

And finally, has anyone seen same problem when renaming directories?
I'm basically implementing a "real time" (ie. almost instant access to current 
data) background reindexing with Lucene, and need renameTo() only for
directory renaming, and was wondering if I should add similar workaround to my 
code, even before hitting the problem (better safe than sorry).

To make search available without interruptions I'm copying existing index 
directory to a work dir, do updates (for all changed docs remove from + add 
to index), remove old index and rename working dir to index. During first 
steps old index is still available, and during last steps I'm just 
temporarily sync'ing search engine object to prevent new queries from using 
that index (that's the main idea -- implementation is bit more complicated as 
it's possible some searches have already started using that index).

-+ Tatu +-


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