Downloading to an unmounted location allowed

Bug #480429 reported by Tristan
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DC++
Confirmed
Low
Unassigned
LinuxDC++
Confirmed
Medium
Unassigned

Bug Description

Steps to reproduce:
- Make sure that your partially downloaded files directory is on your regular hard drive
- Select a file to "download to..."
- Choose a directory on a USB memory stick or hard drive as the download location
- Wait until the file starts downloading
- Unmount your USB memory stick/hard drive

The files will continue downloading, but be stored in the unfinished download directory, the directory structure is not preserved
Actions like "open file" in the finished downloads list won't work

 While not a critical issue, I had trouble finding my files after this happened once. It'd be good if a popup could appear that informs you that your files will be stored in the unfinished downloads directory, or perhaps create a directory in the user's home directory that contains the files in the proper file hierarchy

Either way, in good linux spirit, it's good if the user is told what's happening to their file system.

using linuxdc++ 1.0.3. on Kubuntu 9.10

Thanks for all your hard work! linuxdc++ is working very well!

Tags: core
Revision history for this message
Razzloss (razzloss) wrote :

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

Changed in linuxdcpp:
importance: Undecided → Medium
status: New → Confirmed
Razzloss (razzloss)
tags: added: core downloads
Revision history for this message
poy (poy) wrote :

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%)"

Revision history for this message
eMTee (realprogger) wrote :

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...

Revision history for this message
Steven Sheehy (steven-sheehy) wrote :

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?

eMTee (realprogger)
Changed in dcplusplus:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
maksis (maksis) wrote :

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

Fredrik Ullner (ullner)
tags: removed: downloads
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.