Another similar cause may happen with some multi media library managers that are monitoring new files added to a directory: once the completed file is closed by Limewire, Windows will broadcast an event to applications that are currently monitoring the content of the directory containing it as its content has just changed, and if this application starts scanning the file immediately (for example to detect its embedded MP3 tags) and replies immediately to this event before performing its scan in the background, then that multimedia library manager will effectively be putting a shared lock on that new file before LimeWire gets a chance of moving it to the final target directory.
This problem is not specific to LimeWire but affects any application that create and close files before renaming them or moving them or using them for other purpose.
Solution1: don't add (or exclude) the LimeWire "Incomplete" shared directory to the list of directories that your multimedia library manager will monitor. Make sure that this multimedia manager will not list any file found in the "Incomplete" directory!
Solution2: upgrade your multimedia library manager (or other similar tools that are monitoring changes in some directory to update its internal status) so that it will either wait at least a couple of seconds before scanning new files, or will not reply immediately to the "directory changed" event as long as it is scanning the new file contents (however during that time the application that created it (i.e. a downloader thread within LimeWire) will be blocked during its close-operation as long as the library manager has not replied to the Windows event.
If MacOSX has a similar directory-change monitoring event, it may be affected as well. This is not a bug of MacOSX in that case, but a bug of these monitoring applications that are not respecting the contract about the directory-changed event and how to use it safely.
Last edited by verdyp; March 9th, 2004 at 06:12 PM.
|