WinRAR & updating file with LFN in archive bug

[compie]

I have an .rar archive which contains among others the file "bla bla bla bla\hello.txt".
When I go inside the archive, in the the directory bla bla bla bla, and then try to edit the file hello.txt totalcmd ask if i want to unpack the file to a temporary directory and edit it. I choose yes, edit the file, and close the editor. Then totalcmd starts winrar to repack the file into the archive. But it repacks the file as "blabla~1\hello.txt" in the archive.

[Clo]

2compie
Hi !
• I just made a similar test using an eleven-character dir.-name.
• I don't confirm. The long name is kept.
• Please, verify in Option >>> Configuration >>> Packers
- You must choose WinRAR.exe to handle long names and not Rar.exe which makes DOS names...

  Kind regards,
Claude
Clo

[compie]

I can reproduce the error. I use WinRAR 3.20 and not the dos rar.exe. The version of total commander is 6.02.

[Black Dog]

[face=courier]On 09-03-2004 16:53:47 +0000 compie wrote:

c> I have an .rar archive which contains among others the
c> file "bla bla bla bla\hello.txt".
[^Y]
c> But it repacks the file as "blabla~1\hello.txt" in the
c> archive.

1. Christian just "love" RAR by some strange kind of love, so the same bugs are back time after time with persistence of Terminator. Well, I already got used to it %).
2. Yep, confirm your report with WinRAR.
3. AFAIK this is not about LFN in general but only filenames/paths with space(s).
4. The thing are even more funny now with 32 bit console rar.exe - if I want to pack some file with space(s) in path(s), it adds BOUTH LFN and SFN names of the same dir to archive in some mysterious way (of course with a help of the listfile generated by Commander), so if you pack folder with a name "Long name folder" you will get

Long name folder\
LONGNA~1\

inside Longnamefolder.rar - yes, now Commander kills spaces in archives names created by 32 bit console rar.exe like in good old times.

BTW, it was already fixed two or even three times (sorry, can't remember for sure %):

_________transmission_from_HISTORY.TXT__________

22.10.02 Fixed: RAR32 and ACE32: Also allow long names with spaces as archive names
22.10.02 Fixed: 32-bit external packers: Set source dir to long name before calling packer
[^Y]
12.08.02 Fixed: Make Wincmd work with current RAR.EXE version (Winrar.exe already worked, use this if possible)

_______________end_of_transmission________________[/face]

[compie]

Can somebody reproduce the bug with the latest version of WinRAR (3.30?). If it works correct with the latest version then everything is ok, otherwise things need to be fixed by Christian.

[Black Dog]

[face=courier]On 10-03-2004 20:34:19 +0000 compie wrote:

c> Can somebody reproduce the bug with the latest version of
c> WinRAR (3.30?).

This is not about RAR... %)[/face]

[MiToZ]

This is like major bug, especially for those frequently using winrar ... is there a quickfix expected? ...

... sucessfull rar file unpacking in this version is variable of directory name (spaces, path depth) and result is that sometimes unpacked files land in source (and not destination) directory, and sometimes winrar reports an error and same thing happens ...


MS

[compie]

I want to know the same: Is this goint to be fixed quickly. Christian?

[DKG]

I had a lot of problems with WinRAR 3.20, that's why I went back to 3.0
This is not the perfect solution, but it's a packer, it will pack in both version as well!!

I have to test 3.30, is it works fine?

[ghisler(Author)]

I will have a look at it.