TC7.5b8 & rc1 - Can't find external archiver
Moderators: white, Hacker, petermad, Stefan2
TC7.5b8 & rc1 - Can't find external archiver
Hello,
since beta8 i have the following problem:
First of all, i use the fhRAR plugin, with the internal rar extractor the problem doesn't exist (but i can't extract password protected multi volume archives).
If i try to extract a rar archive to a folder, which i want to create during extraction i get the error message "Can't find external archiver" and the settings dialog shows up.
For example, left i'm inside a rar archive, right i'm in the Folder C:\Temp and i want to extract into the folder C:\Temp\Test and "Test" doesn't exist before extraction.
I press F5 and in the upcoming dialog i expand the Path from C:\Temp to C:\Temp\Test. After pressing OK i get the error above.
I seems that the error only occurs if the hole path (in the example C:\Temp\Test) is longer than 52 chars.
If i extract in an existing folder there is no Problem.
I hope i revealed understandable, and sorry if my english isn't perfect
since beta8 i have the following problem:
First of all, i use the fhRAR plugin, with the internal rar extractor the problem doesn't exist (but i can't extract password protected multi volume archives).
If i try to extract a rar archive to a folder, which i want to create during extraction i get the error message "Can't find external archiver" and the settings dialog shows up.
For example, left i'm inside a rar archive, right i'm in the Folder C:\Temp and i want to extract into the folder C:\Temp\Test and "Test" doesn't exist before extraction.
I press F5 and in the upcoming dialog i expand the Path from C:\Temp to C:\Temp\Test. After pressing OK i get the error above.
I seems that the error only occurs if the hole path (in the example C:\Temp\Test) is longer than 52 chars.
If i extract in an existing folder there is no Problem.
I hope i revealed understandable, and sorry if my english isn't perfect
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
I doubt by myself that its related to 52 char path length, i know that 52 is a atypical number for such a problem, but i can reproduce this on any drive, in any folder on my pc.
I know that tc meanwhile can handle encrypted rar archives, but it still can't handle encryptet rar archives if filenames are encrypted. Therfore i still need the fhRAR plugin, even if its outdated.
If anyone has a better solution to handle such archives i gladly would uninstall fhRAR.
I know that tc meanwhile can handle encrypted rar archives, but it still can't handle encryptet rar archives if filenames are encrypted. Therfore i still need the fhRAR plugin, even if its outdated.
If anyone has a better solution to handle such archives i gladly would uninstall fhRAR.
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
It is surprise for me to know that TC doesn't support browsing of some kind of RAR archives...
I may suggest you to try Multiarc with original WinRar's Unrar.exe tool (it is freeware; you should find addon for Unrar.exe and add its text into Multiarc.ini and associate rar format with Multiarc.wcx) - it should support all kind of RARs. But you should turn on the console window of Multiarc - Unrar.exe will ask you for a password.
BTW, unrar.dll shipped with TC and unrar.dll which I get from rarlab.com (a bit newer version) both contain function RARSetPassword. So I think it is a TC misfeature that TC don't ask user for a password for list archive (for unpack TC does).
Anyway, console unrar.exe may list encrypted multi-volume archives, so Multiarc should help you to browse such archives in TC.
I think this may help while listing archive by unrar.dll:
I may suggest you to try Multiarc with original WinRar's Unrar.exe tool (it is freeware; you should find addon for Unrar.exe and add its text into Multiarc.ini and associate rar format with Multiarc.wcx) - it should support all kind of RARs. But you should turn on the console window of Multiarc - Unrar.exe will ask you for a password.
BTW, unrar.dll shipped with TC and unrar.dll which I get from rarlab.com (a bit newer version) both contain function RARSetPassword. So I think it is a TC misfeature that TC don't ask user for a password for list archive (for unpack TC does).
Anyway, console unrar.exe may list encrypted multi-volume archives, so Multiarc should help you to browse such archives in TC.
I think this may help while listing archive by unrar.dll:
Code: Select all
====================================================================
void PASCAL RARSetCallback(HANDLE hArcData,
int PASCAL (*CallbackProc)(UINT msg,LPARAM UserData,LPARAM P1,LPARAM P2),
LPARAM UserData);
====================================================================
Possible events
UCM_NEEDPASSWORD - DLL needs a password to process archive.
This message must be processed if you wish
to be able to handle archives with encrypted
file names. It can be also used as replacement
of RARSetPassword function even for usual
encrypted files with non-encrypted names.
P1 Address pointing to the buffer for a password.
You need to copy a password here.
P2 Size of the password buffer.
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
2MVV
You go the way, which is explored 5-6 years ago by author of fhRar. Whatfor, if mr. Ghisler don`t want to change this behaviour? You can read here or search on a forum for "fhrar".
As for your suggestion on multiarc: do you know, that TC don`t load plugin for rar until you define this extention directly? And if you do so, you broke repack of rar`s and must write packing part of addon also. Aside of that, why is multiarc better than fhRar?
You go the way, which is explored 5-6 years ago by author of fhRar. Whatfor, if mr. Ghisler don`t want to change this behaviour? You can read here or search on a forum for "fhrar".
As for your suggestion on multiarc: do you know, that TC don`t load plugin for rar until you define this extention directly? And if you do so, you broke repack of rar`s and must write packing part of addon also. Aside of that, why is multiarc better than fhRar?
Thanks for the answer. Unfortunately i couldn't get to work with MiltiArc (I haven't found a rar addon for it yet).
It tested a little bit with TC and RAR. The only thing which doesn't work is is listing files in encrypted archives with encrypted filenames. Everything else ist working as it should.
@Ghisler
Would it be a big problem, to ask for the password before the files are listed?
\\edit
OK, I draw the question back. But in my opinion this is realy disappointing.
It tested a little bit with TC and RAR. The only thing which doesn't work is is listing files in encrypted archives with encrypted filenames. Everything else ist working as it should.
@Ghisler
Would it be a big problem, to ask for the password before the files are listed?
\\edit
OK, I draw the question back. But in my opinion this is realy disappointing.
- ghisler(Author)
- Site Admin
- Posts: 48088
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Indeed at the moment it's not planned to show files in RAR archives if the file names are encrypted now. Reason: TC would have to ask for the password all the time even during searches, or every time you enter an archive. Also the user may actually want to hide the names when choosing this option.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
-
- Power Member
- Posts: 556
- Joined: 2006-04-01, 00:11 UTC
A bistable command cm_AskForPassword could be done for solving a problem with archive search. That would be an universal solution. As it is now, it is not upon to user if he wants to be asked for password, but to plugins writers, that is imho not right. 7zip.wcx for example also tries to ask password when searching in archives and this cannot be changed. If TC would have an internal "flip-flop", all plugins could be switched simultaneously. The second possibility is to extend plugin API in order to give an information to plugin,that supports encrypting, if it is called for search, or from filepanel. TC must call "ask for password" dialog only for ctrl+down then, not when searching. The worst case from all possible is as it is now (imho).