LimeWire 2.6.5 on Mac OS X 10.2.1

Quite frequently, the fileurns.cache file becomes trashed, requiring LimeWire to once again scan every single shared file. With many shared files, and especially many large shared files, this can consume quite a good deal of time, during which unscanned files are not shared.

One problem seems to be that LimeWire will rescan the shared files at every startup, and will rewrite the fileurns.cache file at quit. However, the rewritten fileurns.cache file appears to only contain data for the rescanned files, thereby reducing the effectiveness of having the cache in the first place: at the next startup, LimeWire will be unable to share some files without rescanning them. If LimeWire is started and rapidly quit, this can amount to most if not all files. LimeWire should preserve the existing contents of fileurns.cache when validating it or adding shared files; it should only REMOVE entries from the file when they are no longer actively shared.

Another problem seems to be that fileurns.cache is truncated if LimeWire crashes. This seems excessive and unnecessary. LimeWire should NEVER truncate a file, even on crash, even if this requires never keeping fileurns.cache opened for writing by making updates to another file and then replacing fileurns.cache with it as appropriate.

Finally, when LimeWire first creates fileurns.cache, it does not write cache data to the file until it has scanned all shared files. With lots of large shared files, it could take hours to complete the scan. If LimeWire never runs long enough for the scan to complete, fileurns.cache will never contain any data. Data should be written to this file incrementally in order to address this issue.

Another seemingly related problem is that limewire.props frequently gets trashed the first time LimeWire is run after a user logs in. It is unlikely to happen for subsequent runs of LimeWire if the user remains logged in.

The symptoms of this problem are a loss of all preferences, and the user is shown the initial configuration window.

Incidentially, RUN_ONCE in limewire.props seems to be set to "false" at all times now, even after the first run of LimeWire. In previous versions, this property was set to true.

Mark