Lucene - Core
  1. Lucene - Core
  2. LUCENE-674

Error in FSDirectory if java.io.tmpdir incorrectly specified

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.1
    • Component/s: core/store
    • Labels:
      None
    • Environment:

      Reported on a Linux system under Tomcat

      Description

      A user of the JAMWiki project (http://jamwiki.org/) reported an error with the following stack trace:

      SEVERE: Unable to create search instance /usr/share/tomcat5/webapps/jamwiki-0.3.4-beta7/test/base/search/indexen
      java.io.IOException: Cannot create directory: /temp
      at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
      at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
      at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
      at org.jamwiki.search.LuceneSearchEngine.getSearchIndexPath(LuceneSearchEngine.java:318)

      The culprit is that the java.io.tmpdir property was incorrectly specified on the user's system. Lucene could easily handle this issue by modifying the FSDirectory.init() method. Currently the code uses the index directory if java.io.tmpdir and org.apache.lucene.lockDir are unspecified, but it could use that directory if those values are unspecified OR if they are invalid. Doing so would make Lucene a bit more robust without breaking any existing installations.

        Activity

        Hide
        Hoss Man added a comment -

        This sounds like a very similar issue to some past discussion about the path specified when opening a directory, and what to do if it doesn't exist (ie: create it, or throw an error) ... in general i think it would be unadvisable to assume that if java.io.tmpdir refers to a bogus directory that we should use the index directory, because that could lead to situations were typo result in errors silently being ignored to the possible extend of index corruption.

        (consider for a moment: two lucene based apps running in two seperate JVM instances on the same machine, attempting to use hte same index directory; one with a properly set java.io.tmpdir and one without – they will most likely crash hard because they would wilently use completley differnet directories for managing locks).

        As with the discussion about index directories that don't exist, applications that want to silenetly assume that a bogus java.io.tmpdir property should result in using the index directory for lock files can get that behavior if they want (by testing java.io.tmpdir themselves, and explicitly constructing a SimpleFSLockFactory() on the directory they want to use) but Lucene should not make any assumptions about what the client application wants in the case of garbage input.

        Show
        Hoss Man added a comment - This sounds like a very similar issue to some past discussion about the path specified when opening a directory, and what to do if it doesn't exist (ie: create it, or throw an error) ... in general i think it would be unadvisable to assume that if java.io.tmpdir refers to a bogus directory that we should use the index directory, because that could lead to situations were typo result in errors silently being ignored to the possible extend of index corruption. (consider for a moment: two lucene based apps running in two seperate JVM instances on the same machine, attempting to use hte same index directory; one with a properly set java.io.tmpdir and one without – they will most likely crash hard because they would wilently use completley differnet directories for managing locks). As with the discussion about index directories that don't exist, applications that want to silenetly assume that a bogus java.io.tmpdir property should result in using the index directory for lock files can get that behavior if they want (by testing java.io.tmpdir themselves, and explicitly constructing a SimpleFSLockFactory() on the directory they want to use) but Lucene should not make any assumptions about what the client application wants in the case of garbage input.
        Hide
        Ryan Holliday added a comment -

        I'm not sure if "the user specified the wrong directory" is necessarily the correct situation here. Unless a user specifically sets the org.apache.lucene.lockDir property, they aren't really choosing the lock directory location - Lucene uses the java.io.tmpdir property as a default, without any input from the user. A user who runs into this problem will see only something like "Cannot create directory: /temp" in their logs, and then has to go through the source code to figure out why anything is trying to create that directory.

        The code already defaults to using the index directory for lock files (which the user DID specify) if the org.apache.lucene.lockDir property and the java.io.tmpdir properties are not set - it doesn't seem like much of a stretch to just modify the code to also use the index directory if at least the java.io.tmpdir property is invalid.

        Show
        Ryan Holliday added a comment - I'm not sure if "the user specified the wrong directory" is necessarily the correct situation here. Unless a user specifically sets the org.apache.lucene.lockDir property, they aren't really choosing the lock directory location - Lucene uses the java.io.tmpdir property as a default, without any input from the user. A user who runs into this problem will see only something like "Cannot create directory: /temp" in their logs, and then has to go through the source code to figure out why anything is trying to create that directory. The code already defaults to using the index directory for lock files (which the user DID specify) if the org.apache.lucene.lockDir property and the java.io.tmpdir properties are not set - it doesn't seem like much of a stretch to just modify the code to also use the index directory if at least the java.io.tmpdir property is invalid.
        Hide
        Michael McCandless added a comment -

        Newer versions of Lucene (since 2.1) now store the lock file in the index directory by default.

        Show
        Michael McCandless added a comment - Newer versions of Lucene (since 2.1) now store the lock file in the index directory by default.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ryan Holliday
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development