Quote:
Originally Posted by remi
|
OK. Logging was set to ALL. It happens once every 15-20 downloads. But how useful is that really? The failure is clearly happening in rename function when some other file has a lock on it. It could be QuickView or Finder that's generating a thumbnail of the file and that won't be captured in a log. I doubt the log will be more detailed than what I've provided you above. But I will post the whole thing once it happens again.
Quote:
Originally Posted by Jiaz
jd does an atomic rename :p but i guess you are downloading from a hoster which does not allow resume. in that case jd thinks following
download failed = because rename still happens in download core and fails
then no resume possible = so lets delete the part file again because we cannot resume it.
you should check/find out why the file is blocked! the file must not be opened when the rename is going to take place
|
Jiaz, yes, I do use some hosts with no resume (i.e. free mode) and from what I've seen when this happens, the file is downloaded 100% and there's a checkmark icon beside the filename and then when it tries to rename, the whole entry (checkmark et all) is grayed out and the file's gone and you have to re-download it.
What I don't understand is this: if the rename fails, why is JD deleting the file? Why doesn't it fail gracefully and say: "Rename failed of file.part, rename it manually". Why does the failure of rename operation result in such a catastrophic failure of whole file being deleted? That makes no sense to me if it's an atomic operation. If it were atomic, wouldn't I be left with two files: file.wmv and file.wmv.part?
Even if some other app has a lock on a file (you open partially downloading file in VLC for example), a failure of rename should not result in a file being deleted.