"Claude LaFrenière" wrote:
Absolutely - thanks for reminding me about the horror of built-in ZIP
support, which has the following issues at least:
- s-l-o-w- listing of files if "large" .ZIP files present in folder
- doesn't show size of .ZIP in Status bar, only number of files
- Find (Search) finds files in .ZIP, but doesn't show path
- navigating into .ZIp spawns new single-pane window
- extra ?exploitable risk surfaceauto-exposed to content
- failure to extract silently aborts copies on certain errors
Norton Commander for DOS had seamless support for .ZIP as if they were
directories over a decade ago. MS still can't catch up.
Three of the above go beyond nuisance value:
1) Find (Search) finds files in .ZIP, but doesn't show path
That's really bad news, if you keep locally-visible .ZIP as quick data
backups, because there's a risk someone will Search for a file, find
it in the backup, and make changes to that instead of the "live" one.
2) Extra ?exploitable risk surfaceauto-exposed to content
We've already had an example of exploitation of .ZIP, and another case
where an av signature update from Trend crashed systems due to buggy
archive extraction code. If malware were to exploit the handler that
counts files in a .ZIP when all you wanted to do was search for
something, or list the files in a folder, then that's a dangerous
opportunity for dropped malware to auto-integrate and resist removal.
Safety Rule #33: Do NOT "touch" risky material ahead of users' intent.
What's "risky"? Anything the user has indicated no intention to
"open", for starters. Let's say I have a HD that contains known
malware file BLAH.ZIP that I can't delete because it is "in use", or
the active form of the malware defends it. I drop the HD into another
PC, so the malware isn't running, and navigate to where the file is -
but as soon as the folder containing BLAH.ZIP is *listed*, the code
exploits the OS and now I've infected the host PC.
3) Failure to extract silently aborts copies on certain errors
This bit me in the ass, big time. I wanted to transfer some files
between arbitrary PCs; copy to new PC, delete off old PC. I used a
USB stick to do this, after zipping the files so they'd fit.
I copied the .ZIP from USB to the destination PC, "explored" the .ZIP
via native .ZIP support, and copied the files. No errors. As is my
habit, I selected all in both windows, and checked Properties to see
that file and byte counts matched. They did not; the .ZIP contained
more files than where I'd copied the files to.
If I'd gone ahead and deleted the .ZIP and original files off the
source PC, I'd have been knee-deep, head-first in the dwang.
I repeated the operation; same mileage, until I used a different USB
stick. WinZip opened the bad .ZIP with no errors, but reported an
invalid compression error in one particular file; it could copy out
all the others. When re-testing with XP's native .ZIP compression, it
could copy all the other files, but if the bad one were included, it
would abort the copy at that point, failing to copy anything after
that file had been encountered. And NO error messages at all.
Yup. I hate brain-damaged software that thinks it knows best. Can
you say "hubris"? I do, daily; read a typical post of mine that
breates poor software quality, and I'll bet you there will be at least
two typos in that post, only one of which would have been deliberate
as a subliminal example of hubris.
If humans can't code 5 paragraphs of their native human language
without screwing up, what chances fault-free million-line code?
More on killing AVI lookup? We need ways to risk manage all of these
"persistent handlers" (code that "touches" content when all we wanted
to do was list files in a folder) as well as background file
"touchers" such as indexing, SP, SFP, thumbnailers, and the .PF
(PreFetch) defrag-info-fathering system.
The AVI thing is a bitch, because the system will trudge through an
entire 600M movie file if it's corrupted, looking for tags or
whatever. User thinks it's a lockup, hits reset; now you have
secondary file system damage, which "kill, bury, deny" AutoChk
converts to broken files no longer detectable as broken files.
And so even a pseudo-crash can cause real damage.
-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
