JDownloader Community - Appwork GmbH
 

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 21.12.2009, 05:53
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default "Extras" Extract does not use password

I had downloaded an encrypted archive. Part 1 in one package, and the rest in a second package. (Actually all were originally in the first package, but I accidentally deleted them, so I made a new package for the rest.)
I had included the password in the second package, and this was listed in the "Auto" line.

After all parts were downloaded JD had not extracted them (autoextract was on). So I started it using r-click "Extras/Extract".
JD did not use the password in the package, it tried to crack it, then asked for the password.

I can understand why it didn't autoextract, as the package as listed was incomplete, though all the parts were actually downloaded, but why didn't it use the password set in the package?

Last edited by Gweilo; 23.12.2009 at 05:08.
Reply With Quote
  #2  
Old 21.12.2009, 09:57
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,434
Default

The "extraction set" is the set of all parts to be extracted together (identified by the name, without the part number). They should be in the same package for things to work the way you expect. If you had merged the two packages, the password in the "Auto" line would have been preserved.

The extraction is always based on part1. You supplied the password with part2, but not part1. So, JD didn't have a password for the file it had to extract from (the rest are considered continuation, not the main file).
Reply With Quote
  #3  
Old 21.12.2009, 10:16
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default

As I said, the original package was deleted, so I couldn't combine them. (I was deleting some redundant links and somehow selected all of them.)
I suppose I could have recopied the links for part 1 and JD would have skipped downloading them as already existing and proceeded to extract "normally".

However, the password is a property of the PACKAGE, not a particular part. Once I tell it to extract the package, it should use the package password. What's the point of storing a package password if it isn't referenced?

Last edited by Gweilo; 21.12.2009 at 10:25.
Reply With Quote
  #4  
Old 21.12.2009, 11:33
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,434
Default

Sorry, the way archives work is that only the package containing part1 counts. So if that package doesn't have the password, there is no way to use it. As I said, part1 represents the archive, while the rest of the parts are just continuations.

This is how archives work. There is nothing that the JD team could do to fix it, becaue the second package is not involved in the extraction (the files are used from your disk).

Ideally, once you recovered the links, you would have merged the two packages. Auto passwords are kept when you merge packages.

You could also have copied the password to the package containing part1.
Reply With Quote
  #5  
Old 21.12.2009, 13:36
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default

Quote:
Originally Posted by drbits View Post
Sorry, the way archives work is that only the package containing part1 counts. So if that package doesn't have the password, there is no way to use it. As I said, part1 represents the archive, while the rest of the parts are just continuations.
This is how archives work. There is nothing that the JD team could do to fix it
Are you supposing this, or are on the JD team?


Quote:
Originally Posted by drbits View Post
Ideally, once you recovered the links, you would have merged the two packages. Auto passwords are kept when you merge packages.

You could also have copied the password to the package containing part1.
No, neither, because the first package had been deleted (as mentioned).
I can and did easily work around this. But I still think JD should be able to do this by itself.

Quote:
Originally Posted by drbits View Post
because the second package is not involved in the extraction (the files are used from your disk).
Yes it was.
I right clicked on the package, selected "Extras/Extract". JD then proceeded to extract the archive. I did not use the top "Addons" menu where you select arbitrary files to unrar. It was launched in the context of the package. It tried to unrar the files in that package without further prompting, until it asked for the password. But it should equally have been able to use the password in that same package where it found the files listed.

Last edited by Gweilo; 21.12.2009 at 13:39.
Reply With Quote
  #6  
Old 22.12.2009, 07:55
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,434
Default

Quote:
Are you supposing this, or are on the JD team?
I am not on the JD team, but I know about how archives are structured. I mis-typed. It is not the package containing part1 that counts; it is the part1 file that counts.

In part, because I help answer questions, I have had the privelege of learning from some of the JD team members over the past couple of months.

If you asked for Extras/Extract on the package containing *.part2.rar (or .zip), but not *.part1.rar, then JD passed the request to unrar.exe, which found *.part1.rar and began the work from there.
----------
You are right, JD could have passed the password from the package to unrar.exe.

However, JD uses a kludge (a trick) to see if the file has a password. The kludge looks to see if the part1 file contains an encrypted header. The kludge failed to find the part1 file, so it returned the wrong answer. I found out about the kludge, because there is at least one kind of file that you have to extract manually (not within JD) and Jiaz (a team member) explained the problem to me.

If I have a chance to discuss this with one of the team, I will mention your issue.

At least one of the team always monitors these messages, so if this were considered an urgent issue, somebody from the team would have changed the status of the message.
Reply With Quote
  #7  
Old 22.12.2009, 13:04
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default

Quote:
Originally Posted by drbits View Post
You are right, JD could have passed the password from the package to unrar.exe.

However, JD uses a kludge (a trick) to see if the file has a password. The kludge looks to see if the part1 file contains an encrypted header. The kludge failed to find the part1 file, so it returned the wrong answer.
I don't think so.
After I started the extract, JD did know the file was encrypted, it was trying to crack the archive, but failed and prompted for the password.
So I'm pretty sure that JD had analysed the part1 file, even though it was not listed in the package.
If the password had been in its list of previous passwords, I'm sure it would have found that unassisted, but this was a new one.

And why is this marked "solved"?
If that means "ignore" then say that, or if it really has already been fixed, please confirm.
Reply With Quote
  #8  
Old 22.12.2009, 14:16
remi
Guest
 
Posts: n/a
Cool

At the moment there are no devs. Please, have some patience.

I don't know who marked the thread as [solved]. This must be a mistake.
Reply With Quote
  #9  
Old 22.12.2009, 19:49
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default

Quote:
Originally Posted by remi View Post
At the moment there are no devs. Please, have some patience.
I did not express any impatience.

This is obviously a trivial bug.
I'd just like it noted so the next time someone is looking at the unrar code they might think about fixing it.

I wanted to know why it was marked "Solved", as I'm aware that "Solved" can mean "Won't fix" in some contexts.
Reply With Quote
  #10  
Old 23.12.2009, 00:29
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,434
Default

I asked that it be marked solved (blame drbits).

It is a Won't fix. It is rare enough and easy enough to work around that there is no reason to make JDownloader more complex to support this case. Expansion is a "nice to have", but not part of the core purpose of JDownloader (downloading a list of links). As you know, the JD team is already understaffed.

JDownloader is only supposed to expand when all of the parts are in the package. In the future, it might check for that and refuse your request to expand.

In fact, it is a surprise that it worked at all. This is a case of the person who supports unrar.exe adding what should be unnecessary code.

If you need to manually expand, you can use 7zip (or IzArc or WinRAR).
Reply With Quote
  #11  
Old 23.12.2009, 05:07
Gweilo's Avatar
Gweilo Gweilo is offline
JD Legend
 
Join Date: Mar 2009
Posts: 725
Default

Quote:
Originally Posted by drbits View Post
JDownloader is only supposed to expand when all of the parts are in the package. In the future, it might check for that and refuse your request to expand.
So, you suggest the team do work to make JD less useful, rather than more.


Quote:
Originally Posted by drbits View Post
It is rare enough
Not rare at all.

Often I get parts of a fileset in different JD packages, in different sessions after the original package has been deleted, or not using JD at all.

If I shutdown JD or it crashes, the completed downloads will be deleted from the download queue (I know this is a setting that can be changed, but it's commonly used), leaving a package that only has half the parts of an archive in it, while the rest are already downloaded.

JD's unrar is unique with its ability to try a list of passwords (I've heard of utilities that do this, but never actually found one). None of your suggested alternatives can do that.

The ONLY problem this time is that the archive was encrypted with a new password, not in the previously used list.

Quote:
Originally Posted by drbits View Post
the core purpose of JDownloader (downloading a list of links)
No, the "core purpose" is to deliver the file with the least amount of hassle to the user. What I want is the file "X.avi", not 43 encrypted RAR files.
The whole rigmarole of archiving, splitting, captchas, downloading, passwords, expanding is the tedious crap JD was designed to handle.

Thanks for your time.
But I hope the actual team sees it differently.
Reply With Quote
  #12  
Old 23.12.2009, 11:30
remi
Guest
 
Posts: n/a
Cool

As you know I only speak for myself and not for any team or committee. I wish the devs won't spend their time on this one, but nobody will stop you to find a developer that will program it for you.

Boris Brodski from 7-zip is preparing a much better integration of 7-zip in jD. Let's hope the many limitations and problems of the unrar plug-in will be solved by the 7-zip integration.
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 23:51.
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 - 2024, Jelsoft Enterprises Ltd.