problem inside 2 archives containing identically named files

[tomte]

example one:
File1: X1.ZIP -contains: test.txt
File1: X2.ZIP -contains: test.txt

Press F3 to view the first test.txt inside X1.ZIP in the left pane - press F3 to view the second test.txt inside X2.ZIP in the right pane:
Warning: Overwrite %temp%\+tc\test.txt?
Compare by Contents of the two test.txt's does work though (the right file goes to "_tc_" instead of "_tc").

example two:
File1: Y1.ZIP -contains: X.ZIP -contains: test.txt
File2: Y2.ZIP -contains: X.ZIP -contains: test.txt

Enter X.ZIP inside Y1.ZIP in the left pane, try to enter X.ZIP inside Y2.ZIP in the right pane:
Warning: Overwrite %temp%\+tc\x.zip? (if you press Ok you end up with the contents of the 2nd x.zip in both panes)

One way to fix this could perhaps be to always use "_tc_" for any temp-archive operations from the right pane - not only for compare by contents?

[ghisler(Author)]

This is normal because the viewer uses the same location for all files. This is done to avoid an overflowing TEMP directory. Compare by contents uses two locations in such a case. I have no intentions to change this.

[Flint]

This is done to avoid an overflowing TEMP directory.

How can it be overflowed if TC detects when the user leaves the archive and automatically removed it from the TEMP directory? Why cannot TC behave here identically to how it hebaves in Compare by Content (unpack to different subdirectories)?

This problem is very annoying.

[petermad]

Why cannot TC behave here identically to how it hebaves in Compare by Content (unpack to different subdirectories)?

I agree - why not?

[ghisler(Author)]

Why cannot TC behave here identically to how it hebaves in Compare by Content

Because you cannot only open two files this way, but hundreds from different archives!

[Flint]

Because you cannot only open two files this way, but hundreds from different archives!

Well, TC remembers about each of them, and it will remove each of them as soon as the user leaves them, won't it?

[bdk]

I started a thread on this issue not knowing about this thread. Reposting here. It concerns the same issue but from a slightly different angle. I really think this is something the author should look into.

Hi

I have searched the archives but could not find anything covering this precise issue.

I post this as a bug, though it's probably a known issue. Please bare with me.

The problem arises when I want to compare two archives that contains other archives navigating in one archive in each pane. If the "inner" archives have the same name, TC will try to unpack the inner archives to the same temp area, thus prompting me if I want to overwrite the already unpacked archive. Did anybody understand that? To reproduce:

Create an archive b.zip containing some files. Create an archive a1.zip, containing the b.zip and some files. Create another archive a2.zip containing the b.zip and some files. The task is now; verify that the b.zip in a1.zip contains the same files as b.zip in a2.zip.
Navigate inside a1.zip on the left pane and navigate inside a2.zip in the right pane. Navigate inside a1's b.zip and then try to navigate inside a2's b.zip. You will be prompted if you want to overwrite the files already unpacked on the temp area (the files from a1's extracted b.zip). What you need to do to make this work is to rename a2's b.zip to b2.zip. Than you are ok. But one does not really want to modify archives just to be able to compare them. It kind of defeats the purpose.

Isn't it possible for TC to use a more specific temp catalog structure for the unpacked files? If the temp catalog structure contained the name of the outer archive (a1 and a2), this would be no issue.

Hopefully someone understood what I meant.

regards
bdk

[StatusQuo]

Press F3 to view the first test.txt inside X1.ZIP in the left pane - press F3 to view the second test.txt inside X2.ZIP in the right pane:
Warning: Overwrite %temp%\+tc\test.txt?

This is normal because the viewer uses the same location for all files.

That could be solved by the user him-/herself, if one could rename the second file (or archive) target before unpacking to temp dir.
Unfortunately now in the overwrite-dialog there is only "Rename existing target file" (which renames the one already opened by a lister task, so a refresh or loading the next part will fail there).

How about letting the user specify, that FILE.EXT will be unpacked as i.e. FILE2.EXT, before Lister is loaded with it,
or that INNER.ZIP should be copied to temp as i.e. INNER2.ZIP before opening?

[Flint]

How about letting the user specify, that FILE.EXT will be unpacked as i.e. FILE2.EXT, before Lister is loaded with it,
or that INNER.ZIP should be copied to temp as i.e. INNER2.ZIP before opening?

IMHO, it would be much easier just to implement the automatic renaming inside TC, because in each case (whether the file was renamed by TC or by the user) TC will have to look after the unpacked files and remove them when the Lister is closed (or the user went out of the internal archive).

[StatusQuo]

IMHO, it would be much easier just to implement the automatic renaming inside TC, because in each case (whether the file was renamed by TC or by the user) TC will have to look after the unpacked files and remove them when the Lister is closed (or the user went out of the internal archive).

I thought from the user's view it would be easier to recognize each file, if the user decides about the new name himself/herself (which TC would have to store, shure).

A standard rename for the second file would be OK for me, too. Maybe like "Compare by contents", by adding an underscore (_) to the beginning of the name.

[bdk]

I do not understand why TC just can't use the whole path of the file it is unpacking as the path in the temp directory. If test.txt lies in both d:\testdir1\testdir1\a1.zip and d:\testdir2\testdir2\a2.zip, why not just use the path d_testdir1\testdir1\a1.zip\test.txt and d_testdir2\testdir2\a2.zip/test.txt as the paths in the temp directory instead of just test.txt? Or something like that? The underscore to separate the drive letter is just a suggestion. Is this difficult to implement? As far as I can see, this will solve all problems related to unpacking of files with the same name. This will also make it possible for the user to navigate inside the temp directory in a sensible way if that is required. I often do this after decompiling java .class files from inside an archive. If TC were to rename files at it's own will, the structure of temp directory could be difficult for users to navigate.
Every file do have their own unique path if one consider both the path to the outer archive and any path inside the archive. If this path could be "remembered" as one traverses inside an archive and just added in front of the path TC uses today we are home free. Or? I know that this approach could potentially lead to some very long paths in the temp directory (if one has archives inside archives inside archives inside archives and so on), but I guess this is not a problem with modern operating systems. Or?

regards,
bdk

[Flint]

but I guess this is not a problem with modern operating systems. Or?

Or.
Even on WinXP path lengths cannot exceed 260 characters (or, more correctly, they can exceed this value, but in most programs such files will be inaccessible). Taking into account that default TEMP directory is located at c:\Documents and Settings\<user_name>\Local Settings\Temp\ which is minimum 49 characters already, the paths will go beyond the critical value very easily.

[bdk]

Ok, thanks for the info, Flint.

But I still think something should and could be done with this behavior. Maybe generate a random number and add this to every unpacked file? Maybe use paths as I have suggested, but truncate somehow if the paths get too long. This will not be full proof, but will work in 99% of the cases (only cases where the truncated paths are equal will fail), whereas todays approach works in 0% of the cases. I think that's quite an improvement.

I hate to see this behavior stay unchanged, as it really bugs me in real cases, and not just in made up special cases. I tell all my fellow employees that TC fixes and can handle everything, and I hate to tell them that 'no, TC cannot compare archives with the same name inside other archives'. The workaround is as stated before, to rename one of the two files having similar names. This is quite easy to do, but changing the actual archives one wishes to compare is not good.

But I think I have stated my point. Hopefully the author will take note of this discussion and make the, by far, best working tool I have ever used even better.

regards,
bdk

[ThiefMaster]

Why not simply use temp files and delete all of them on exit?
At least make it possible via a .ini setting - it's really annoying e.g. if you want to look at code from two versions (e.g. to compare manually without the built-in compare util)