Bug report: Expand ZIP file in tree view fails

[skyhighsmile]

Hi,

I found 2 bugs in the handling of ZIP files in the tree view.  The 2nd one is cosmetic, but the first one limits the functionality for long directories.

Version: 1.4.0.1, xplorer2 lite
OS: Windows XP Professional, SP2, updated with all the latest patches.

Bug #1:

When I double-click a ZIP file, the contents of the ZIP file are shown in the file view tab, and the ZIP file usually shows in the tree view pane as if it was a directory - this is good.

But sometimes when I double-click a ZIP file, the contents of the ZIP file are still shown, but there is an error sound, and the ZIP file doesn't show in the tree view.  I tried to figure out what caused this - I thought it might be total path length, or number of levels, or some combination, but it was inconsistent.

File name length does make a difference, though, and sometimes, if I get the error, but then rename the ZIP file to a shorter name, it opens OK.  The odd thing is that, if I successfully open any ZIP file within a directory, then I can open all other ZIP files in that directory fine after that - even if the same ZIP file caused an error before that.  For example, if I get the error, rename the ZIP file to a shorter name, open it OK, then rename the ZIP file to the longer name again, then I can open it using the longer name.

To reproduce:
1. Create a directory structure 'C:\Level 001\Level 002\Level 003\Level 004\Level 005'.
2. Copy a ZIP file into the Level 005 directory and rename it to 'Test.zip'.
3. Double-click on the ZIP file - there is an error sound, and it doesn't show in the tree view.
4. Move the ZIP file to the Level 004 directory.
5. Double-click on the ZIP file - it now shows in the tree view.

Bug #2:

The tree view doesn't update when ZIP files are added, removed, or renamed - it always keeps the names of any ZIP files which were opened previously.

To reproduce:
Perform steps 1-5 from Bug #1, above.
6. Rename the ZIP file (in the Level 004 directory) to 'Test01.zip'.
7. Double-click the ZIP file.
Result: Look in the tree view - 'Test.ZIP' and 'Test01.zip' are now both shown in the tree view, even though only 'Test01.zip' exists.

Questions:
* Are these bugs fixed in the professional version?
* Is there any way to get xplorer2 to automatically show the ZIP files in the tree view (so I don't have to double-click on them for them to show up)?


*Cheers*

[nikos]

zip folders are a bit of an afterthought in both windows and x2, which explains some of what you observe

when the tree doesn't refresh on its own properly then use ctrl+R to force update it

i'll see if any of these problems are easy to fix

[TurnItUpSome]

I use a product called FreeZip that adds options "Unzip" and "Unzip here" to the right-click menu.  When selecting either of these options using x2, the unzipped files are placed at the top of the directory tree on the respective drive, but they should be going into the current folder.  These options work correctly when using the Windows Explorer.

[nikos]

i've used a lot of unzipping programs with shell context menu extensions and none had such problems... looks like this is a problem with your freezip, not x2!

[TurnItUpSome]

Granted, the problem is probably specific to the Freezip program.  However, Freezip does work as expected in Windows Explorer, so when executed within x2, it apparently can't tell it's location based on something within the environment.

A useful tool like x2 shouldn't "break" other software, causing it to not function as usual.  It makes me a little squeamish about running any critical software within x2.  What if I navigated to a sub-folder on the boot drive and executed some software that would ultimately delete the current folder and all sub-folders?  It may attempt to delete everything on the boot drive.

X2 is a nice tool, but my belief is that any "burp" caused by running software within x2 should be addressed quickly and not passed off as an issue with the other software.

[nikos]

think about it: broken software=1, non-broken={all the rest}
is that x2's fault?

[TurnItUpSome]

I was not putting blame on anything or anyone.  It is the nature of the IT world to have issues and conflicts between software, operating sytems, and hardware.   As to Freezip being only "1" known (so far) piece of software affected, the majority of time IT personnel spend writing code is usually for handling the "execptional" cases.

Freezip is not "broken".  It functions unexpectedly only when running it within x2.  If x2 is intended to be a true replacement for Windows Explorer, then it hasn't reached its goal.  Any software executed withing x2 should function exactly as it does when executed from within Windows Explorer.  If there is a known, unresolvable conflict, then the issue should be noted in documentation and/or release notes as a courtesy to users of the software.

X2 is a fine, well designed product.  If x2 is not intended to be a reliable replacement for Windows Explorer, then so be it.  However, until it can fully replace Explorer, I will use it on a very limited basis and never execute any other program or application from withing x2.