Replace UC2 in TC packer menus with anything another

Only forum where polls are allowed. You may announce a new poll in the matching support forum.

Moderators: sheep, Hacker, Stefan2, white

Replace UC2 with 7zip, Uha, FreeArc, etc... ?

No, leave UC2
1
2%
Replace with 7zip
14
33%
Replace with UHA
0
No votes
Replace with FreeArc
3
7%
Replace with something customizable by user
24
57%
 
Total votes: 42

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2016-06-19, 19:44 UTC

Try adding shortcuts to external packer list. When user presses Alt+-, listbox gets focus and it may activate an item by first character. So first characters should be different, e.g.:

Code: Select all

0: ace
1: arj
2: lha
3: rar
4: uc2
5: 7z
6: sqx
7: bz2
8: wim
9: xz
A: cab
B: uha
C: arc
D: z
It would also be nice to be able to pin some packers to the beginning of list, e.g. some INI option with list of extensions to be shown first.

User avatar
MaxX
Power Member
Power Member
Posts: 659
Joined: 2012-03-23, 18:15 UTC
Location: Earth

Post by *MaxX » 2016-06-20, 14:25 UTC

2MVV
Is there any need to pin?
AFAIK, you can move needed wcx plugins to the top of the list in wincmd.ini. Not-existing EXE packers would not be shown. Overview of 8-10 plugins in scrolllist should be enough.

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2016-06-20, 14:46 UTC

Problem is that INI files doesn't keep order of entries so items may be reordered on e.g. adding/removing/editing items. Of course you can rearrange them manually every time but it would be easier to be able to pin specific items.

User avatar
MaxX
Power Member
Power Member
Posts: 659
Joined: 2012-03-23, 18:15 UTC
Location: Earth

Post by *MaxX » 2016-06-20, 14:55 UTC

2MVV
INI files doesn't keep entry order
Strange. I've never had such a problem. My config is pretty clear for years and nothing have happened with it.

The order you set will specify the queue to call these wcx. It is useful (for me) and easier than one more parameter for each plugin.

User avatar
Lefteous
Power Member
Power Member
Posts: 9457
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous » 2016-06-20, 14:59 UTC

2Dalai
I would separate the internal packers from plugins, though, maybe with some thin line in the list. And I wouldn't drop the little star that visualizes an external packer is needed for that format.
For me this information doesn't really help me in selecting the desired archive file extension.
It would also be nice to be able to pin some packers to the beginning of list, e.g. some INI option with list of extensions to be shown first.
I agree customizing the order would be helpful.

User avatar
Dalai
Power Member
Power Member
Posts: 6747
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai » 2016-06-20, 15:44 UTC

Lefteous wrote:For me this information doesn't really help me in selecting the desired archive file extension.
No, but it shows the user which packers come from a plugin and which ones are internal packers that TC can process without any plugins/DLLs. Maybe some "Configure plugins" button that opens TC's packer plugin settings could achieve this instead.
I agree customizing the order would be helpful.
Indeed.

Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups

User avatar
Lefteous
Power Member
Power Member
Posts: 9457
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous » 2016-06-20, 15:52 UTC

2Dalai
No, but it shows the user which packers come from a plugin and which ones are internal packers that TC can process without any plugins/DLLs.
Yes but why is this relevant? For me it's important that plugins are not perceived as something on-top but as something integral.

User avatar
Dalai
Power Member
Power Member
Posts: 6747
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai » 2016-06-20, 16:07 UTC

2Lefteous
Well, plugins are just that: plugins. Users may report bugs in packers that come from plugins, not from TC itself. Or they may wonder why some TC installation doesn't offer packer format XY that they're used to see. So I don't think it's a good idea to make users perceive them as integral part of TC.

Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2016-06-20, 16:09 UTC

Maybe mark external packers with * and plugins with **?

User avatar
Lefteous
Power Member
Power Member
Posts: 9457
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous » 2016-06-20, 16:56 UTC

2Dalai
Well, plugins are just that: plugins. Users may report bugs in packers that come from plugins, not from TC itself. Or they may wonder why some TC installation doesn't offer packer format XY that they're used to see.
This information might be useful in a certain context but not in the packer dialog where it's just distracting. 'Oh no 7z is just a plugin. Better not pack with it.' - come on! I don't think there is an issue -> There is the packer plugin settings dialog where the information can already be found.

User avatar
MaxX
Power Member
Power Member
Posts: 659
Joined: 2012-03-23, 18:15 UTC
Location: Earth

Post by *MaxX » 2016-11-06, 20:28 UTC

Looks like no news for the topic. So sad...
Let UC2 become history, please!
Lut us use something that works on x64 and does not waste space on the archivers list.

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2016-11-07, 08:10 UTC

I would be more happy if I could open pack dialog with pre-selected packer of my choice BTW (via some internal command or something else - there was such suggestion).

brentved@yahoo.dk
Junior Member
Junior Member
Posts: 3
Joined: 2019-05-25, 02:23 UTC

Re: Replace UC2 in TC packer menus with anything another

Post by *brentved@yahoo.dk » 2019-05-25, 02:52 UTC

FreeArc aperas to be dead too, last update marts 2014. Sad, it was blazing fast, and it was beating Rar in compression ratio in every test i made.

hi5
Member
Member
Posts: 179
Joined: 2012-11-03, 11:35 UTC
Contact:

Re: Replace UC2 in TC packer menus with anything another

Post by *hi5 » 2019-11-11, 22:29 UTC

Bump for removal of UC2 in 9.5 :)
F4MiniMenu - Open selected file(s) from TC in defined editor(s) - A (minimalistic) clone of F4Menu
Source at GitHub (AutoHotkey) - TC Forum thread

User avatar
DrShark
Power Member
Power Member
Posts: 1348
Joined: 2006-11-03, 22:26 UTC
Location: Kyiv, 68/262

UC2-related bugs (Re: Replace UC2 in TC packer menus with anything another)

Post by *DrShark » 2019-11-12, 20:51 UTC

hi5 wrote:
2019-11-11, 22:29 UTC
Bump for removal of UC2 in 9.5 :)
Christian Ghisler is considering removing the UC2 support. However, I reported some remaining UC2-related bugs to Christian by email and asked to consider a possibility to fix at least some of them before removing UC2 support from TC. Christian Ghisler then wrote he will consider fixing at least one of that bugs.

I see no point to post that bugs as separate topics in Bug Reports forum, instead I'll just describe them below, so if there will be a decision to remove UC2 support before getting any of mentioned bugs fixed, this post may be separated from this topic and moved to Behavior will not be changed subforum.

Bugs:

1 and 2. Bugs 1 and 2 (related). For both following bugs it looks like TC doesn't pass some correct 8.3 name at some stage of dealing with UC.EXE, so I consider below as TC bugs. To reproduce:
1) open in both TC panels the same path, but using different names:
in 1st panel open its long name path, so it will look like c:\longnametest\1\,
and 2nd pane open its 8.3 path, so it will look like c:\longna~1\1\
2) make a long name file in this dir with f.e. "name.eng.txt" as a long name with its "nameen~1.txt" as a 8.3 one
3) Execute cm_switchlongnames command, so TC will show 8.3 name of file "name.eng.txt" in 1st panel
4) bug 1: in a panel with 8.3 path (2nd panel in above steps),
try to pack nameen~1.txt: it will fail with error from UC2:

Code: Select all

SYSTEM ERROR: path not found (attempting to create C:\LONGNANMETEST\1\U$$VRKAI.TMP)
Packing from panel with long path (2nd panel in above steps) will work fine, you'll get an archive nameen~1.uc2 with a file nameen~1.txt inside. We'll use it to reproduce next bug.
5) bug 2: try to open the archive nameen~1.uc2 we made in step 4 from 1st panel (where current path is a long name path), TC will show an error:

Code: Select all

---------------------------
Total Commander
---------------------------
Error in packed file c:\longnametest\1\nameen~1.uc2!
---------------------------
ОК   
---------------------------
Notes: unpacking archives with Alt+F6 works for both long and 8.3 path panels.
Bugs doesn't seem to occur if cm_swithlongnames mode is off (=TC shows long names in panel filelist).

3. Packing to long named UC2 archive isn't correct due to bug in UC.exe:
if we're packing files to .uc2 archive, UC.exe cuts archive name to 12 characters,
but it's not a unique 8.3 name of a file, but just 1st 12 characters of a long name we had in TC Pack Files dialog.
Which means if we're packing using TC some files to UC2 archives with different long names with the same first 12 characters, all files will go to the same UC2 archive which has that 12 first characters as its name.

Possible solutions for TC as shell:
a) cosmetic one: TC can itself cut the name of UC2 archive to 12 characters and show it like that it in Pack Files dialog, and show a warning if user will edit it to try to make it longer with the message that it will be cut to 12 characters anyway;
b) solution that will allow to pack to long name archives.
uc2 can create 60-byte empty archive (I sent a sample of such archive to Christian Ghisler by email).
TC can itself create such archive with a long name from Pack Files field.
This archive will have unique 8.3 name. TC can then pass that 8.3 name to UC.exe passing the list of files from source panel to pack, this will work fine.

4. Serious problem, due to bug in UC.exe: it CAN'T pack files (not folders!) with at least some non-English names, like files with Cyrillic character-names to UC2 archives.
Even though UC.EXE works only with 8.3 names, due to this bug it can't pack files with cyrillic long names even if latin short names are present for such files and are passed to UC.EXE.

However, since UC.exe packs files without cyrillic long names (so they only have latin 8.3 names) just fine,
there is a possible solution which uses symlinks, so it requires NTFS and should work on Vista+.
It may be used to pack such files and store their 8.3 names in resulting UC2 archive.

The point of solution is that TC as a shell may create a tree structure with full path and 8.3 names of files with cyrillic names we're packing somewhere in a root of %tmp%\_tc (assuming this is NTFS location) and pass this tree as a list to UC.exe.
UC.exe packs the content of original files if symlinks are passed to it, so this solution will work.

There is no need to for complicated filtering non-English long names to create symlinks only for them, you can just add this as an option "Don't store long names in uc2", so TC will re-create the tree of all original dirs and files 8.3 names and pass that to packer.

5. This bug if half of TC and half of UC2, and was partially fixed in 2010:
HISTORY.TXT wrote:22.01.10 Fixed: Open an UC2-packed file could leave a file "U$~reslt.ok" in directory of the archive -> explicitly delete it
However, under following coditions the file U$~RESLT.OK still appears:
1. Start TC, dirs in left & right panels may be completely different.
2. Open uc2 archive in left panel.
3. Press Tab to switch to right panel.
4. Refresh right panel with Ctrl+R: you'll see U$~RESLT.OK file there.

This U$~RESLT.OK is created only 1st time I open uc2 archive in certain panel.

Problems caused by this bug: U$~RESLT.OK file appears and stays undeleted in a path of panel opposite to one where archive is opened, and the timestamp of a folder in that opposite panel changes to a time of that U$~RESLT.OK file creation.
Android 4.3.1 no root, kernel 08.09.2016; Vista Home Premium SP2 rus 32 bit
TC #149847 Personal licence

Cuz we're all in this together, We're here to make it right

Post Reply