#1
|
||||
|
||||
"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. |
#2
|
||||
|
||||
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). |
#3
|
||||
|
||||
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. |
#4
|
||||
|
||||
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. |
#5
|
||||
|
||||
Quote:
Quote:
I can and did easily work around this. But I still think JD should be able to do this by itself. Quote:
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. |
#6
|
||||
|
||||
Quote:
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. |
#7
|
||||
|
||||
Quote:
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. |
#8
|
|||
|
|||
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. |
#9
|
||||
|
||||
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. |
#10
|
||||
|
||||
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). |
#11
|
||||
|
||||
Quote:
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. 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. |
#12
|
|||
|
|||
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. |
Thread Tools | |
Display Modes | |
|
|