Despite what I myself mentioned - that it causes CPU resources to become
overloaded - I think what "Lostgallifreyan" wrote was right when he said :
"Whether a task manager always interprets that as actual CPU hogging when
it's not, I don't know" and in my experience, always, when a "bad" floppy
(or corrupt cd/dvd for that matter) is clicked-on in Windows Explorer, I
*can* simply press on the right-hand "close" [x] and that instance of
[explorer] *will* close...

==

Cheers, Tim Meddick, Peckham, London. :-)




"J. P. Gilliver (John)" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In message <ir06tc$j17$(E-Mail Removed)>, Tim Meddick
> <(E-Mail Removed)> writes:
>>XP is a more complex piece of software than Win 9x, and goes about trying
>>to read data from a damaged disk differently, and tries more methods in
>>the attempt. This can result in Explorer locking-up CPU resources for
>>some time if it does not have any initial success.
> []
>>Also, if you do use Explorer (as I sometimes do, not realising there may
>>be a problem with a disk) - and find that CPU usage has reached maximum
>>and no-data is being read from the floppy - then you can always simply
>>close that instance of Windows Explorer, and the drive-read operation
>>will also be terminated - then simply just re-open another Explorer -
>>avoiding the damaged disk again.
> []
> Not with that XP system: if explorer seems to be getting nowhere, then
> attempting to close that Explorer instance (by clicking the X) usually is
> ignored too. (Or may generate an error message, after a _long_ time.) If
> I attempt to close it from task manager, that succeeds, but usually
> closes _all_ Explorer windows.
> --
> J. P. Gilliver. UMRA: 1960/<1985
> MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
>
> Dailysex, or is it spelled dyslexia, rules KO! (Dr[.] J.[ ]B.[ ]Davis)

In message <Xns9EEB259853CDEzoodlewurdle@216.196.109.145>,
Lostgallifreyan <no-(E-Mail Removed)> writes:
>"J. P. Gilliver (John)" <(E-Mail Removed)> wrote in
>news:(E-Mail Removed):
[]
>Ok, I think the browser comparison I made is flawed, as browsers expect to
>wait. A few timers holding on till timing out isn't enough to halt much in a
>system with timers to spare, but if enough hang waiting, maybe so, or if the
>stuff that does come in demands immediate resource-hungry actions, then
>things can go very agly, like those pages with about 15 flash movies all
>trying to run at once, those are ALWAYS browser-crashers here. (I got help on
>ways to sort that; just haven't made time to look into those much yet).
>
>I think the thing with the floppy is twofold, one is it's not expecting to
>have to wait much, if it works, it doesn't wait. The other thing is that it's
>a very old subsystem, from times when there was no notion of multitasking. It
>wasn't designed in any way to either expect to wait, or to give way if it had
>to, so it simply doesn't give way. This doesn't explain the 'how' much, but I
>think it explains the 'why'. I predict that if you can examine it enough
>you'll see that the CPU isn't busy, it just waits in line like all the rest,
>but where the delay is, I don't know. As the same drivers seem to be used
>(according to driver details in the device manager), the same thing could
>happen if there was a dodgy hard disk. I think I've seen it happen with a bad
>CF card in an ATA adapter.
[]
The floppy is used to move log files from the HD of the '95 system to a
network drive on the XP system. (If I'm in a hurry, I have a reliable
floppy to do it with.) If it shows problems (usually when the XP system
is reading the 58x k files; the 41 k files usually move no problem), I
scan the floppy, on the '95 system, to find the new dud sectors and mark
them. It is during this scan that the '95 system goes treacly - but it
doesn't stop altogether. One of the other tasks I do on it has a
progress bar, which does move - just incredibly slowly.

Also - new question - when a floppy (or other disc) is being scanned
(from Properties, Tools), does it re-scan sectors that had already been
marked bad? I had assumed it didn't, but since it's taking longer and
longer (I'd say it's up to ten or twenty minutes now), I think it must
be doing so.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

I had lunch today in a restaurant where the food was abdominal. - G4PKP's
bienapropism list

In message <Xns9EEBEAE508FEzoodlewurdle@216.196.109.145>,
Lostgallifreyan <no-(E-Mail Removed)> writes:
>"J. P. Gilliver (John)" <(E-Mail Removed)> wrote in
>news:(E-Mail Removed):
>
>> Also - new question - when a floppy (or other disc) is being scanned
>> (from Properties, Tools), does it re-scan sectors that had already been
>> marked bad? I had assumed it didn't, but since it's taking longer and
>> longer (I'd say it's up to ten or twenty minutes now), I think it must
>> be doing so.
>>
>
>I don't know. Too long since I did it.. If you have a disk with enough bad
>sectors that it takes that much longer, you have a problem, rescan or no. One
>possibility is that it's not the disk at all, but the drive, if you see it on
>several disks. Some drives are belt driven, the belts stiffen, eventually
>falling apart. Check for any sign that the disk mechanics aren't responding

No, definitely just the one floppy - the other one works fine. I'm
really, just out of curiosity, seeing how long the floppy will keep
working! I presume until there is some corruption in the place it keeps
the bad sector table and/or root directory.
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

I had lunch today in a restaurant where the food was abdominal. - G4PKP's
bienapropism list

In message <Xns9EEBEDB583363zoodlewurdle@216.196.109.145>,
Lostgallifreyan <no-(E-Mail Removed)> writes:
>"J. P. Gilliver (John)" <(E-Mail Removed)> wrote in
>news:(E-Mail Removed):
>
>> No, definitely just the one floppy - the other one works fine. I'm
>> really, just out of curiosity, seeing how long the floppy will keep
>> working! I presume until there is some corruption in the place it keeps
>> the bad sector table and/or root directory.
>>
>
>Got a microscope? Could do worse that look at the disk surface to see if

I do, as it happens: one of these USB jobbies. Bought on a whim, but has
actually proved invaluable at work (which involves servicing and
repairing electronics, including some fine surface mount stuff, and also
connectors that exhibit interesting faults; for both of these, the mic.
has proved most useful). But that doesn't answer my original question.

>it's grinding its surface to very tiny bits. Not least because it it is, it's
>also doing unspeakable things to your drive heads. Just wiping the exposed
>bit of disk with a (very) slightly dampened bit of toilet paper after pulling
>the shutter aside, then looking for rust-coloured stains will tell you
>plenty.

Doesn't actually seem to be shedding: I've looked at the surface (with
the naked eye only) quite frequently, and it looks shiny. I'm surprised
- by my reckoning it's up to about 15% dud, so I thought I'd be able to
see something by now!
>
>I remember there is a small procedure you can use in DEBUG.EXE to wipe the
>start sectors of a disk. That was a hard sisk thing though, not sure how to
>make it do floppies.. Equally a disk editor (Norton's DiskEdit.exe) can zero-
>fill the start sectors quickly in raw access mode. If you can reformat and
>use it as normal after that you'll know what was wrong. Enough to know it
>wasn't physical, if nothing else. Another thing to try is a raw imager, copy
>every bit to a new known good disk, then try that to see if acts the same.

I'm pretty sure it is physical - I can't think of any "mechanism" in the
world of bit patterns that would make the floppy seem to gain apparently
dud sectors on a more or less daily basis, as it is doing.

What I started the thread about was, purely, puzzlement as to why
scanning a faulty floppy should slow the system to a crawl. (The '95
system; and why attempting to _read_ that same floppy on the XP system
should give it a strange case of the wobblies.) **I normally have no
wanted data on the floppy when I do the scanning - it's empty.**
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

I had lunch today in a restaurant where the food was abdominal. - G4PKP's
bienapropism list