TC11.02RC5 Bug with Symbolic Links and Extracting Files

[SniperSnX]

Hello,

i recently discovered a bug on the latest TC.

Whenever i extract from within an archive on one side to a folder on the other side which is a subfolder under a Symbolic Link Folder, the symbolic link folder is replaced by a normal folder overwriting the symbolic link.

This is a new behaviour, haven't noticed on older versions of TC.

Hope this descriptions helps.

With kind regards.

[ghisler(Author)]

NOT confirmed. I don't see a single reason why this should happen. Complex code would be needed to do something like this, it doesn't just happen out of the blue. Are you perhaps unpacking with a plugin?

Can anyone else reproduce that?

[petermad]

I cannot confirm this either, I have tried with both a symlink and a junction parent folder.


2SniperSnX
How do you make the symlink?
How do you extract the files - do you highlight the archive and press Alt+F9 or do you go into the archive and press F5?
Which version of Windows do you use?
Which version of TC do you use - you write the latest - is that TC 11.01 or TC 11.02rc5?
Do you use 64bit TC or 32bit TC?

[SniperSnX]

Well i figured it out on a fresh install of Windows 11 Enterprise (en-us_windows_11_business_editions_version_23h2_x64_dvd_a9092734.iso)
As stated i use the TC11.02 RC5
64bit Version as Administrator
for Link Creation i use the Link Shell Extension 3.9.3.5
the Symbolic links i tested were local folders and network share folders.

i go into the archives with enter and delete files / folder and copy them to the other side.

zip files work without problems.
rar archives are the ones which replicate the above behavior. Sorry i wasn't paying attention to that detail.

Looks like it has something to do with the unrar.dll?

If needed, i can provide a video of what i did.

[ghisler(Author)]

Thanks, I can confirm the problem in unrar.dll 6.24, but not in 6.23 and also not in 7.0 beta 1.

Strangely it seems to be at least partially intentional(!) when I look at the sources of 6.24, function LinksToDirs.
It has the following comment:

Code: Select all

// Delete symbolic links in file path, if any, and replace them by directories.
// Prevents extracting files outside of destination folder with symlink chains.

and in extract.cpp:

Code: Select all

  // Common for all archives involved. Set here instead of DoExtract()
  // to use in unrar.dll too.
  // We enable it by default in Unix to care about the case when several
  // archives are unpacked to same directory with several independent RAR runs.
  // Worst case performance penalty for a lot of small files seems to be ~3%.
  // 2023.09.15: Windows performance impact seems to be negligible,
  // less than 0.5% when extracting mix of small files and folders.
  // So for extra security we enabled it for Windows too, even though
  // unlike Unix, Windows doesn't expand lnk1 in symlink targets like
  // "lnk1/../dir", but converts such path to "dir".

In unrar 6.23 it has only been enabled on Unix systems, while in 6.24 it's enabled on Windows too.
So it seems to be some kind of security measure so files don't get extracted to a different location
than the given target directory.

However, it's strange that it doesn't happen in 7.0 beta 1. Since there is no source code for that
yet, I don't know what was the author's intention.

Anyway, I have sent an e-mail to the RAR author about this problem now.

[petermad]

rar archives are the ones which replicate the above behavior.

I can too confirm the behaviour with WinRar 6.24

[ghisler(Author)]

This should be fixed in RC6, please test it!

06.11.23 Fixed: unrar*.dll 6.24.0 was replacing any file system links within the target path with directories. Included new dll provided by RAR author (32/64)

[petermad]

Confirmed fixed in TC 11.02rc6 using WinRar 6.24 for packing

[SniperSnX]

Confirmed! It's working, Thank you for keeping fixes for TC up to date (and really fast too).

[Horst.Epp]

Fix Confirmed.
Even the version 7.0.1 files are still working

[ghisler(Author)]

Thanks for reporting it! The RAR author was very helpful and even provided a modified dll for me, so I didn't have to compile it myself.

Moderator message

Moved to fixed bugs