"could not move file to library"

occasionally after i finish my downloads, after it verify's the file contents, instead of saying "completed" it will say "Could not move file to library"
what does this mean?
am i seeing things?

[stief]

that can happen if the folder for the saved files has lost write permission (depends on your OS), or if the hard drive is full. It used to mean there was an illegal character in the file name, but that cause has been fixed for a while now.

so is there anything i can do to stop that from happening?

my drive isnt full and im running the most recent version of OSX

[stief]

Look on your hard drive to select your download folder (as set in the LimeWire->Preferences-Saving Folder), and choose "Get Info" to see the permissions. It should say your username in' owner' has Access->Read & Write.

For OS 10.2 & 10.3, a Safe Boot and Repair Permissions after major system upgrades is good housekeeping (links are here.

Any ideas about this message coming up? I just started using Limewire today.

[stief]

?? which of the above ideas don't apply?

[elliotst]

I think the references you spoke of are for Macs. I have a pc (I know, to bad....) and still using 98 OS.

I now have more mp3's lined up under the "could not move to library" column, then I have saved to my HD.

Any way I can clear the backlog and get these files moved over?

[stief]

until someone who knows '98 can help, is there a "properties" setting for your saved directory?

LW thinks there is something that is preventing it writing the completed files to your saved folder, as set in the Tools->Options->Saved Folder.

Maybe look there too for clues?

Sorry I can't help more. Good luck anyway.

[verdyp]

I think that this may happen with some old antivirus that are opening and trying to scan files stored in a directory before they are completely finished. When the download ends, the file is closed and the antivirus takes an immediate shared lock on the new file to scan it, preventing the file from being moved.

This problem is not specific to LimeWire and affects other downloads performed in Internet Explorer as well, when it downloads a file to a temporary folder before moving it to the target directory when the download completes. It also affects some FTP clients, and many other softwares that create temporary files before moving or renaming them when the file is complete.

Better try a newer version of the antivirus without this very limitating bug, so that it will scan the files on the fly (while the file is opened and being written) without taking a shared lock on it only after the file has been closed by the application creating or modifying it -- at least an antivirus should scan the file while the application is currently closing the completed file (and the application should then be blocked during the file-close operation until the antivirus scan completes).

--

A shared lock, even if it allows reading the file from other competing applications, prevents any attempt to move, rename or delete the file unless you are using a Unix filesystem where a file can be unlinked from all directories despite it is still active and opened in some applications; this is a great tool to allow easy software updates, but also a security issue as this means that Unix will not prevent all files from being deleted without necessarily hanging your system, but the next time you will reboot, all files will have been deleted. Unix avoids this caveats by allowing you to restrict writes on directories so that files they contain can't be renamed, moved or deleted, despite the files can still be modified independantly of the directory permissions...

[verdyp]

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.