Archived from groups: microsoft.public.windowsxp.perform_maintain (
More info?)
It's incredible.
And the solution is so easy :
a menu to enable/disable only what you need.
And for security it would be better to instal with everithing disabled by
default.
Simple.
For me it's difficult to understand why they don't do that.
I mean : my WinXp is not a demo version to show all the possibility to public.
If i need something i can enable it only when i need it.
One of this days they will understand!
Hi.
"cquirke (MVP Windows shell/user)" wrote:
> On Sun, 19 Jun 2005 13:40:08 -0700, LukeIt
> >"Claude LaFrenière" wrote:
>
> >> > Bug partialy resolved :
> >> > regsvr32 /u zipfldr.dll
> >> > So explorer dosn't try any more to manage zip file and make me loose 1
> >> > minute just to see a directory.
> >> > I've found this on
http://www.winguides.com/registry
> >> > Very big advantage for a very small disadvantage.
> >> > I can manage zip file in many better ways.
>
> 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.
>
> >> > I've found even a way to stop explorer form extracting file information from
> >> > AVI.
> >> > Unfortunately It's not possible to delete this dangerous dll definitively
> >> > because the system restore it automaticaly without asking confirmation
> >> > (stupid system) and if i double click on a zip file the dll is registred
> >> > again.
>
> 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...
> >-------------------- ----- ---- --- -- - - - -
>
Facebook
Twitter
Instagram