Downloading to an unmounted location allowed

The reason why they were left in the unfinished dir is most likely that you didn't have permissions to write to the mount location after the volume was unmounted.

In general this also happens when destination dir becomes full. So I'd say the core should save the files to be copied somewhere (like Queue.xml) and retry the copy later when destination/more space becomes available. Instead of just leaving files to unfinished dir and discarding the directory structure.

--RZ

with the "keep finished files in the dl queue" option on, just running the rechecker should take care of moving such stuck files again. when that option is off, i'm not sure but i think that adding the download again allows one to run the rechecker on it.

as for informing the user, the following messages are already being outputted:
"Unable to move %1% to %2% (%3%); renamed to %4%"
"Unable to move %1% to %2% (%3%) nor to rename to %4% (%5%)"

The quotes above are outputted to the system log (not sure if it can be viewed in LinuxDC++ GUI, its possible in DC++). Thus the user is informed about the failed move operation of the finished files to the destination path. The 0.760 core makes possible to keep finished files in the dl queue, however even the DC++ GUI does not have the possibility to do action with finished files (Shell menu, Open, etc...)...
I think if the user does not keep the downloaded files in the queue, he can find the error message in the log, if he keeps the files then the problem can be handled by introducing context menu actions for finished files. However in the case explained above (and Unable to move %1% to %2% (%3%); renamed to %4% message goes to the log) we must make sure that the finshed item's path points to the actual file stuck in the unfinished folder and not to the original target path where the file failed to move to...

I disagree with the approach that DC++ should keep a list of files somewhere and attempt to move them later. DC++ should simply notify the user in a clear manner and continue. As far as the directory structure, what about modifying the core to store files in the finished dir using their final directory structure? In case of an error, the path in the finished downloads tab would show the actual path to the file in the finished dir (as eMTee mentions) and this would allow the "open file" feature to work as a result.

LinuxDC++ will also show that error message in the status area and log it to file as DC++ does. So LinuxDC++ does notify the user that an error has occurred, although it might be hard for the user to see these status messages since they get overwritten when the next message comes in. Also, most users are probably not savvy enough to check the logs for any issues. What about adding an "Errors" column to finished downloads so users can clearly see there was an issue encountered with this file so they can handle it accordingly?

Another solution might be to put the temp files directly in the destination directory :p