Doug Cutting writes: > Armbrust, Daniel C. wrote: > > The problem I ran into the other day with the new lock location is that Person A > > had started an index, ran into problems, erased the index and asked me to look at > > it. I tried to rebuild the index (in the same place on a Solaris machine) and > > found out that A) - her locks still existed, B) - I didn't have a clue where it > > put the locks on the Solaris machine (since no full path was given with the error > > - has this been fixed?) and C) - I didn't have permission to remove her locks. > > I think these problems have been fixed. When an index is created, all > old locks are first removed. And when a lock cannot be obtained, it's > full pathname is printed. Can you replicate this with 1.4-final? > Hmm. If user A creates a lock in /tmp and lucene crashes leaving the lock, user B won't be able to remove the lock (unless B is root) since /tmp usually has permissions drwxrwxrwt 12 root root 8192 Jul 12 08:50 tmp/ were the 't' means that normal users may delete only their own files (at least on linux and IIRC solaris).
Or did I miss something? Lucene might work around this by creating a directory in java.io.tmpdir setting apropriate permission (can that be done with java os independently?) and put the lock there. Morus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
