[8.0b1] Rar - TC creats a 0 byte filelist on kyrilic folders

[Biozynotiker]

Rar: TC failes to create a filelist for rar, when the selected folders has e.g. kyrilic or polish chars in it.
TC creates a 0 byte filelist in temp folder and rar fails to load that filelist.

[ghisler(Author)]

Not confirmed when using WinRAR.exe (full path must be specified).

[Biozynotiker]

You can use the "calc.exe" instead, TC creates a 0 byte filelist in temp folder.

[ghisler(Author)]

Not confirmed. Maybe you didn't give the full path to calc.exe or winrar.exe? Then TC will create an ANSI list file, because older RAR versions could not handle Unicode.

[Biozynotiker]

Ok, maybe this happens, because i use the %commander_path% variable in the path that point to the exe. My WinRar/Rar.exe is in a subfolder of TC.

[Biozynotiker]

Sorry to bother you with this Christian, but this is very important to me, to understand this.

I'm right, that TC creates file lists that is depending on:
- The given path to exe ?
- The file name of the exe itself (e.g. WinRar.exe / Rar.exe / Calc.exe / Hugo.exe)?

If the above is true, than TC will do the following (?):
- For example, "WinRar.exe" is located in "C:\Program Files\WinRar\WinRar.exe" and this is also set in TC config, than the created file list is Unicode?
- But the file list is Ansi, when the same WinRar location is in the "path" environment variable and only the "WinRar.exe" is launched from TC?
- So there is also no way to use an renamed "WinRar.exe", because this will create an Ansi file list?
- There is also no way to use (newer) "Rar.exe" instead of "WinRar.exe", although the Rar.exe is able to read Unicode file lists (-sc switch)?

If this all is true, than please please please add an option in the Packer Configuration, nearby the "[x] Use internal un-RAR only if possible". Something like "[x] Create only Unicode file lists"
or like this "[x] Use compatibility mode for older Rar versions".

Edit:
This seems the only way to use a portable TC+Rar combination, because WinRar isn't portable at all.
For Rar.exe you can use the "rar.ini" file for configuration, or in my case, i wrote a self written wrapper (TC > Wrapper > Rar.exe) for this.
It seems, that every exe, that have not "WinRar.exe" in the filename, produce a ANSI file list.

[ghisler(Author)]

I tried with %commander_path% too, but it works without any problems! However, you must make sure that you use 32-bit winrar.exe.

TC checks whether the called program is 32-bit or 16-bit, and sends only the short DOS names to 16-bit or command line programs. That's why you need to use WinRAR.exe, not RAR.exe.

[Biozynotiker]

Ok, to get this work, I tried the following:

- Clean Windows 7 64Bit Install
- Clean WinRar 4 32Bit Install
- Clean TC 7.56 and TC8.0b2 Install (both 32Bit)
- Set the Full Path to the Winrar.exe in TC
- Create a Rar Archive by selecting three folders with polish / kyrilic / german umlauts in it
- TC creates a 0 byte file list in Temp folder

Now, there are 2 possibilities:
- The used chars in my folders produce a unwanted situation
- Or you maybe tested it with polish / kyrillic as subfolders (this works even with rar.exe)

In the case, the used chars of the folders creates this, ill try to post it here (hope this is shown correctly):
- folder "ąęźżńł" (polish chars)
- folder "äöü ÄÖÜ ß" (german stuff, with whitespace)
- folder "абвгдеж эюя" (russian chars, with whitespace)

I hope someone can reproduce this.

[ghisler(Author)]

I tried with exactly your names and WinRAR 4.01 freshly downloaded, and it works just fine both with 32-bit AND 64-bit WinRAR.exe. I really have no idea what is wrong on your system.

[Biozynotiker]

I repeat the above test, but use a 32 Bit Windows 7 and it now works. I don't know what wrong with the 64Bit installation.

ghisler(Author):
TC checks whether the called program is 32-bit or 16-bit, and sends only the short DOS names to 16-bit or command line programs.

- What do you exactly check?
- And why TC fails to create a correct file list on other 32/64-Bit Exe files (e.g. calc.exe, iexplore.exe or something else with given full path)?

I really want to modify my Rar wrapper so, that TC recognize it as "Winrar.exe". But i have to know what TC checks.

[ghisler(Author)]

Here is the function I use:

Code: Select all

function ispackerwinrar(packer:integer;vercheck:boolean):integer;  {0=no, 1=yes, 2=32bit RAR}
{Differences: 0: OEM-chars, short names    }
{             1: ANSI-chars, long names    }
{             2: OEM-chars, long names     }
var packname:tdirtype;
    p:pchar;
    i:integer;
begin
  result:=0;
  if packer=packer_rar then begin
    LoadTcProfileString(pr_captPacker,pr_confRAR,s_defaultRAR,packname,
      sizeof(packname)-3);
    p:=PtrAfterLastChar(packname,s_backslash);
    if strlicomp(p,'winrar',6)=0 then begin
      result:=1;
      if vercheck then begin
        i:=GetVerNumber(packname);
        if (i<>0) and (i<2040) then result:=0; { Error: New Winrar versions don't have any version info!}
      end;
    end else begin  {Check whether it's 32-bit RAR}
      ReplaceEnvVars(PackName,sizeof(PackName)-1);  
      if CheckIf32bitapp(packname) then
        result:=2
      else
        result:=0
    end;
  end;
end;

So TC first looks for name winrar. If yes, it looks for version number: If older than 2.040, then it expects OEM-chars, short names. If there is none or it's newer, it expects ANSI-chars, long names.

Only if the name doesn't contain winrar, TC looks whether it's 32-bit or 16-bit.

[Biozynotiker]

Thanks, this helps me a lot and now i understand, why TC creates ANSI filelists on other Exe files.

Edit:
Modified my rar wrapper and all works fine (renamed to "winrar.exe", version string to "2.5.0.0", parse the -sc switch for rar.exe)
Thanks for your patience!

[ghisler(Author)]

You didn't write anything about a RAR wrapper in your bug report. What exactly did you do?

[Biozynotiker]

As i first reported the "bug", i used a renamed "winrar.exe" in a subfolder of TC.
So TC creates a ANSI filelist and Winrar failed to load a 0 byte filelist.

Than i followed your hints with full path, etc. and TC creates even a 0 byte files list (ansi).
To get a chance to catch the filelist out of the temp folder, i used some other exe files like "calc.exe" (so that TC waits) and I noticed, that the created file list is really 0 byte in size.
At this time i don't know you checks the winrar.exe file. I thought, TC create a file list based on the OS Version.
After you getting me the hint, that TC creates the file list based on the "winrar.exe", i noticed why even my rar wrapper does not work (Thats the reason i wanted to modify my wrapper).

But you are right, that i can't create a correct filelist, even i done clean windows/winrar/tc installation.
So, there *might* be situations, that TC can't get the version string of the "winrar.exe" and creates a ANSI filelist.

Edit:
I done some tests again with a clean windows/tc/winrar install.
So on my Virtual Maschine, there is a 80% chance, that TC create 0 byte(Ansi) file list, when TC is not on the same drive as WinRar.
This would maybe the reason, that this wasn't work on 64 Bit Windows on the test a few posts above.

Example 1 (Seems to Work):
- WinRar installed on "%ProgramDir%\WinRar" ("C:\Program Files\WinRar")
- TC installed "%ProgramFiles%\Totalcmd" ("C:\Program Files\Totalcmd")

Example 2 (Fails to create a non-Ansi file list):
- WinRar installed on "%ProgramFiles%\WinRar" ("C:\Program Files\WinRar")
- Running TC install on "U:\Tools\Totalcmd8", (Packer.exe is pointed to "%ProgramFiles%\WinRar\Winrar.exe")
- Running Portable TC install on "U:\Tools\Totalcmd", (Packer.exe is pointed to "%ProgramFiles%\WinRar\Winrar.exe")
(Portable = Wincmd.ini [Configuration], UseIniInProgramDir=7, InstallDir=%COMMANDER_PATH%)

There must be something strange, that TC can't retrieve the needed information from the WinRar.exe when its not on the same drive as Winrar.
I also done tests with the NTFS permissions set to "everyone", in case this was a permission problem, but no luck.

[ghisler(Author)]

Winrar is on a different drive than TC here too (drive C: vs. drive E:), so that can't be the real problem...