Sunday, February 26, 2006

Windows XP Compressed Folders buggy

For some time now several colleagues have been calling me for help, because they have problems installing a new version of the checkstyle plugin for Eclipse I provided them. Eclipse just won't recognize the plugin after they unpacked the ZIP file to the plugins folder. After some observation it turned out that only Windows XP users are having difficulties.

Wait a second, only Windows XP? No Linux, no Windows 2000 machines, just XP? What difference should there be in the Java world? (Well... I know... But at least the Windows machines should behave identically). At first I could not see anything special on those machines. Eclipse running fine, the checkstyle directory correctly placed under the plugins directory. After some time I noticed that there were far too little files in the plugin's subfolder.

Turns out that it is the Windows XP ZIP file integration into the explorer as "compressed folders". While the ZIP file has been created with WinZip (and extracted with it on the Windows 2000 machines), most of the XP users used the compressed folders function to put plugin into their Eclipse directories. And guess what: It just left out some files, and did not even tell them about it!. So at first glance everything is fine. The extraction completes, you can see the directories fine. But only a more thorough investigation reveals that only about half of the ZIP file's contents have really been extracted. Even better: Running the unpacking again on the same file produces a different set of results! Has anyone seen this behaviour? I cannot believe that they even manage to break a tool they initially bought from a third party company...

This makes me remember that we used to have problems with ZIP files being extracted on Windows 20003 servers, too. However there we did not miss any files, but some jars were corrupted after un-zipping the archive they were contained in. Unzipping the same file again usually fixed the problem, so that we even swapped memory, suspecting a faulty RAM module. For some other reason we switched to using a different (command line) unzip utility and have never seen a corrupted jar again.

No comments: