7z -spf handle

[Hurdet]

TC internal not handle 7z files create with -spf switch?
7z.exe -spf -t7z a dst.7z "c:\Temp\file1.txt" "e:\TEMP\file2.txt"
Note the capital letters in second path name in drive e: .
It not show the driver letter (or C_ E_) but two folder with same name (Temp, TEMP) and with both individual files.
Also I not can use F4 to edit.
Obviously not problem with 7-zip FM.

[gdpr deleted 6]

TC's 7z packer functionality breaks down badly when confronted with an archive having entries having absolute paths (as per -spf switch).
I would consider this a bug.

As you noted, TC fails to show the drive letter in some form when navigating such an archive.

While F3 works, F4 does not work. When pressing F4, TC unpacks the file to its _tc temp folder without issues, using a directory path that contains the drive letter (with the : substituted by a _). But, TC fails to pass the correct temp path to the file to the editor, instead providing in incorrect path.

Also trying to unpack a file having an absolute path using F5 does not work properly (this also includes drag-and-drop copying from one pane showing the content of the archive to the other pane).

F5'ing on a file directly will unpack it with its parent directory.
F5'ing on a directory inside the archive will extract it with the parent directory of this directory.


By the way, i have not tested with UNC paths. Thus, i don't know whether TC handles 7z archives with UNC path entries better, worse or in same manner as absolute paths with drive letters...


Maybe one of the packer plug-ins with 7z support is behaves better than TC's built-in 7z support. But i can't say, since i have not tested any packer plug-ins...

[ghisler(Author)]

Sorry, 7zip archives with absolute paths are not fully supported. They are very dangerous because they could contain paths to system files. TC tries to strip the drive letter and root folder, but it's not always possible.

[Hurdet]

7zip FM does not pose this danger.
However, to overcome it, instead to strip the drive letter, it would be enough to convert it to C_ as it already seems to do.
instead of surprisingly creating C_ when decompress, show it also in packed file viewer to know how it will be decompressed.

[gdpr deleted 6]

2ghisler(Author)
There is nothing dangerous about TC correctly showing the content of such archives, including the drive letter(s) converted to directories (which TC already does when unpacking via F9). Or is this one of those situations where the user has to be killed if he gains knowledge about the actual paths within such an archive?

Also, handling the unpacking of files using F5 correctly shouldn't be dangerous either (as it should naturally not care about the paths in the archive being absolute or not).

[MVV]

I agree that TC should display C_ in archive if it will unpack it as C_, and this should make handling of such archives easier for TC and more transparent for user.