lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morus Walter <morus.wal...@tanto.de>
Subject Re: Lucene shouldn't use java.io.tmpdir
Date Mon, 12 Jul 2004 07:04:43 GMT
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: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message