lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John L Cwikla" <>
Subject Re: FSDirectory patch for file renaming
Date Wed, 19 Feb 2003 04:42:25 GMT

>From the java bug parade:

Other points of interest:

I believe some *nix's fail if you try to renameTo across partitions (which
theoretically correct since it's not possible, but most mv's use cp/delete
to make up for it)

In Win 9*, renameTo is not atomic like in WinNT variants.

----- Original Message -----
From: "Tatu Saloranta" <>
To: "Lucene Developers List" <>
Sent: Tuesday, February 18, 2003 7:54 PM
Subject: Re: FSDirectory patch for file renaming

> 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
> 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
> 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
> 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
> 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 +
> 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
> that index (that's the main idea -- implementation is bit more complicated
> it's possible some searches have already started using that index).
> -+ Tatu +-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message