JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 12.09.2011, 19:10
axelmm
Guest
 
Posts: n/a
Default the same filename => deleting problem

hi,

I observed another issue: If link checking fails (no longer available) JD deletes earlier downloaded file with the same name.

I had a few jobs with exactly the same target filename (from different links, with different sizes), some downloaded, some failed and finally I get nothing :(

I tested again, downloaded one (job#1), made copy and run failing job (job#2) - JD deleted downloaded file (from job#1).

In settings I have "never" delete finished and "automatically change" file name if file exists.
Reply With Quote
  #2  
Old 12.09.2011, 19:12
raztoki's Avatar
raztoki raztoki is offline
English Supporter
 
Join Date: Apr 2010
Location: Australia
Posts: 16,515
Default

Provide us with all the links involved so we can try to reproduce.

Thankyou for your information so far.
__________________
raztoki @ jDownloader reporter/developer
http://svn.jdownloader.org/users/170

Don't fight the system, use it to your advantage. :]
Reply With Quote
  #3  
Old 13.09.2011, 10:36
remi
Guest
 
Posts: n/a
Default

@axelmm

If you Reset the link that 'failed' or a mirror link that is disabled by jD you might delete a partially or completely downloaded file.

If you mean you selected the "Auto rename" option then your problem might be caused by the bug discussed in "auto-rename issue with some plugins".
Reply With Quote
  #4  
Old 13.09.2011, 10:39
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 66,134
Default

can you provide screenshots/example links?
__________________
JD-Dev & Server-Admin
Reply With Quote
  #5  
Old 13.09.2011, 11:56
axelmm
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by remi View Post
@axelmm

If you Reset the link that 'failed' or a mirror link that is disabled by jD you might delete a partially or completely downloaded file.
Is this right ? It shouldn't !

AutoRename*

*-not for reset ??? Is this a joke? It's always safer to have more copies than lose anything!

I had a few (more than 3) links with the same target filename, most from one hoster - Downloaded one after one - if all are ok, then JD autorenames (I can't rename it manually on quee) - but with errors, resuming/restarting one of them I'm loosing done jobs?

I have to stay monitoring JD and quickly rename completed?

Who resets done jobs? How often? Even in this case JD shouldn't delete files, especially completed - ever.


log: http://jdownloader.org/pastebin/52692
links:
**External links are only visible to Support Staff****External links are only visible to Support Staff** - OK
**External links are only visible to Support Staff****External links are only visible to Support Staff** - not found
other in uploaded log? don't remember, already deleted from quee
Reply With Quote
  #6  
Old 13.09.2011, 14:43
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 66,134
Default

rightclick reset will delete an existing file with same filename. that is what reset is for.
there is also a warning dialog about this.


autorename does not delete any files. but it is buggy in old stable so i would suggest to set skip. autorename will work fine with next major update
__________________
JD-Dev & Server-Admin
Reply With Quote
  #7  
Old 14.09.2011, 00:47
axelmm
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by Jiaz View Post
rightclick reset will delete an existing file with same filename. that is what reset is for.
there is also a warning dialog about this.
warning not warns (in polish) about deleting - it's rather "are You sure?"


I think reset is a function that clears job state, set it up from scrach like a new one. In programming it's like a destroing and construct (in this case) job object.

Restarted job didn't wrote earlier even a bit and with no-exist link won't be trying to write a byte - why it deletes a file saved by another job?!

Why checks filesystem in this moment? Adding a new job doesn't delete files.

In "normal" case (existing link) second job fired from quee calls target autorenaming function and then reseted should use a new filename. Make use?

I think that autorename (check existing file) should be called when a job is taken from quee to being processed or even just before first writing/flushing buffer (after connecting and getting data). That would prevent overwriting concurent jobs even in a case where we have a quee with many files from many hosters, all with the same target filename. Of course other settings (for existing file) like "skip" or "ask" make sens only with a "job context". Autorename or replace make bigger sense in a file context. That can't be done with one simple function call

*****
Reset DEFINITELY should delete file ONLY if THAT job wrote to THAT file - this condition is rather simply to implement (one flag) ? - It would be enought for now (with properly working autorename).
*****

There is another "sense question" - after right-click commands I always must click "start quee" (alt-S). It's annoying - "activate" or "resume job" for me assumes "now" and should start quee. There is an autostart quee with starting JD, quee starts from external job adding (flashgot) - why not from job context?? For what reason quee auto-switches to off state? This should be configurable like "Auto stop quee", "Keep quee always started", "Only manual quee stopping". I think that most users starts JD and keep it allways working, from time to time uses pause and nearly not using stop. This can be used more with remote access, in desktop not used=closed program, when needed can be started again.
Reply With Quote
  #8  
Old 14.09.2011, 10:26
remi
Guest
 
Posts: n/a
Default

In my reply I assume you mean 'download' with 'job' and 'download queue' with 'quee'.

jD has no mirror management yet. Such a feature would coordinate and know about the state of all attempts to download a file.

The auto-rename bug makes things worse, but it would ask too much effort to correct that in the current architecture of jD.

Concerning your last remark, jD can't start/resume a download when the download engine has been stopped. Even a "Force download" command can't start it again. You need to start the download engine again yourself.

As some of the problems you mention (not the mirror management) have already been solved in the experimental, Nightly version of jD I would suggest you would become a proud tester of jD. If you want you can run both engines simultaneously as long as you start them from two different folders. You can then give all your remarks in the Nightly forum.

I'm sorry if I didn't understand all you wrote, but please feel free to explain it again.
Reply With Quote
  #9  
Old 14.09.2011, 13:54
axelmm
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by remi View Post
In my reply I assume you mean 'download' with 'job' and 'download queue' with 'quee'.
of course, "my english" - want to write not remembering right words

Quote:
jD has no mirror management yet. Such a feature would coordinate and know about the state of all attempts to download a file.
there is no mirror managament matter (the same filename and size) - similar but other situation: many jobs, different sizes!!, different urls from a few hosters BUT all jobs with the same filename - using autorename is enough - BUT reset/restore job IGNORES a possibility of existing other (and completed) job with the same filename when resume/activate job wouldn't try to write to that file (should rename earlier)

Quote:
The auto-rename bug makes things worse, but it would ask too much effort to correct that in the current architecture of jD.
what about a simple possibility to change manually "write_to" field under job settings-tab - make it editable, not read-only ?

Quote:
Concerning your last remark, jD can't start/resume a download when the download engine has been stopped. Even a "Force download" command can't start it again. You need to start the download engine again yourself.
Sounds bad - like bad usability. Remoting works better than own API? But what about keeping it run all the time? Impossible too? Queue checks a job list and with certain conditions takes off-action - Give me a way to block that action, please. Simply no loop exit, no auto-magic OFF.

Quote:
As some of the problems you mention (not the mirror management) have already been solved in the experimental, Nightly version of jD I would suggest you would become a proud tester of jD. If you want you can run both engines simultaneously as long as you start them from two different folders. You can then give all your remarks in the Nightly forum.
I'll try.

For a mirror problem with auto-rename there is a problem - duplication. jD should be aware about original file name and it's size. Save "filexxxx.ren" with a table of new names and sizes is a simply way. When jD attemps to write filexxxx it simply checks if filexxxx exists then checks if exists "filexxxx.ren" and then finds increment-new-name updating (creating) file-table. For mirrors/more runing engines simply does the same!

That was a simple but usable way - the more usable would be a history-collection-list - a completed job-info archive. There would be a solution for "hmm, I downloaded that file earlier or not?" question. There is no big matter when or where was saved (but with manual write-to paths may be usable), only the most important "IF". For large data that could be a filename-adressed hash-table with file size only for extremally fast checking. Source url's, referrer, comments, passwords etc. could be useful later

Jobs (files) are almost always post-download managed: moved, renamed, unpacked. I know where are "managed" targets, where to search them for (even backuped), but after deleting from queue I'm loosing simple way to detect content-duplications through its original (packed) filename and size. There is much harder to implement but would be priceless. Autorename can be inplemented that way too, but more important is duplicate-earlier_downloaded-detect or for concurrent engines or mirror-duplicate "skip". Of course "library" should be accessible from many engines simultanously for that feature - for prevent simultanous downloads must contain not only finished, strated too. But there is a question if there wouldn't be enough info that other engine finished the mirror-job - concurrent stops duplicating-job. That can be better (simpler to implement) than preventing from starting concurrent mirror-job which (in certain situations - f.e. lost connection) can blocks both processes.

And library accesible through web-api - JUST DREAMING
Reply With Quote
  #10  
Old 14.09.2011, 14:28
remi
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by axelmm View Post
what about a simple possibility to change manually "write_to" field under job settings-tab - make it editable, not read-only ?
Renaming files isn't possible either. See and

Quote:
Originally Posted by axelmm View Post
Remoting works better than own API?
What do you mean?

You can try to keep the download engine running by giving it a fileserve link. It's slow and when it fails it restarts from the beginning.

Quote:
Originally Posted by axelmm View Post
When jD attemps to write filexxxx it simply checks if filexxxx exists then checks if exists "filexxxx.ren" and then finds increment-new-name updating (creating) file-table. For mirrors/more runing engines simply does the same!
I see you know how to do it. Why not participate in the programming itself?

Quote:
Originally Posted by axelmm View Post
a history-collection-list - a completed job-info archive
See

Quote:
Originally Posted by axelmm View Post
And library accesible through web-api
jD has a web interface or do you mean something else?
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 15:21.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.