What I am puzzled about is why a bad floppy sucks away so much in the
way of system resources. Yes, obviously it isn't cost-effective to use
one, so I use a good one, but just on principle, I'd like to know what's
going on:
On the '95 system, if the floppy is bad, the write just fails with an
error message, that isn't a problem. But if I run the (Windows) disc
checking tool under A:'s Properties, it not only runs very slowly - as
I'd expect - but also slows down the response time of anything else the
system is doing, to an incredible extent. Why does the simple task of
checking a floppy for bad sectors hog the processor so much?
On the XP system, if the read fails, it also seems to lock up the
system. I don't know _what_ it is doing: it sits there, not even
accessing the floppy continuously - the light comes on for a few
seconds, then goes off for a few seconds, and eventually - sometimes
after a minute or more - comes up with an error message; again, the
system is a little sluggish to do anything else, though nothing like as
much so as the '95 system. But what is really weird is that it seems to
sulk where the floppy is concerned: once it has decided there is a
problem, it refuses - by going into the
I'll-stop-responding-for-ages-and-then-put-up-an-error-message mode - to
do _anything_ with the floppy, even delete or rename a file, _or use a
(different, good) floppy. Sometimes, if I think it has locked up
completely, I kill the process with Task Manager, which works - XP is
more robust that way - but from the way it does it, it is clearly having
a _major_ effect: it usually closes _all_ explorer windows, blanks and
eventually redraws the taskbar, breaks iconoid, redraws the desktop, and
so on. Again, I can't see why doing something as trivial as accessing a
floppy - even if it's dud - should have such a major effect on the
system. (I also think the XP system is less tolerant of the poor
floppy.)
I repeat, I _know_ a good floppy is only pennies, and I have one: it's
just the principle that bugs me, of why doing such a nominally simple
thing should cripple both systems so much.
(I've included the '98 newsgroup as I thought they might be
interested/have views/answers.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
There is no character, howsoever good and fine, but it can be destroyed by
ridicule, howsoever poor and witless. -Mark Twain, author and humorist
(1835-1910)
If there's any chance a floppy may be compromised, you should not use
Windows Explorer to read the disk - but try instead using a "Window's
Command Prompt" first.
The difference being, if there's not going to be any success in reading the
disk, and you have waited a long time with no success, then all you need do
is press the [Ctrl-C] key combination to discontinue trying to read the
drive.
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.
==
Cheers, Tim Meddick, Peckham, London. :-)
"J. P. Gilliver (John)" <G6...@soft255.demon.co.uk> wrote in message
news:upX0v3Dj...@soft255.demon.co.uk...
> On the '95 system, if the floppy is bad, the write just fails with an
> error message, that isn't a problem. But if I run the (Windows) disc
> checking tool under A:'s Properties, it not only runs very slowly - as
> I'd expect - but also slows down the response time of anything else the
> system is doing, to an incredible extent. Why does the simple task of
> checking a floppy for bad sectors hog the processor so much?
>
Is it really the CPU time it's hogging? (Check in a good task manager..) It
might be the low level driver waiting and timing out and retrying that takes
all the time. Other parts of the system often have to wait for low level
driver accesses to complete, the same sort of thing shows up with browsers
trying to get remote data, etc.
One thing I read about bad floppies, is that it's worth just letting it retry
up to 100 times overnight if need be, that it usually gets a read in the end
if there's no scarring of the disk surface. Another thing I used to do that
often worked, is to gently pinch the sides of the disk together while firmly
turning the centre bit to wipe the disk surface on its liners (Arguably the
100 retries are only doing what the pinch-and-turn does, just a lot more
slowly and gently...). That very oftem improved things. I'd image that disk
then and write the image to a new one if I needd to. (I still have a big
DiskBank.zip full of files I can use in WinImage).
> I kill the process with Task Manager, which works - XP is
> more robust that way - but from the way it does it, it is clearly having
> a _major_ effect: it usually closes _all_ explorer windows, blanks and
> eventually redraws the taskbar, breaks iconoid, redraws the desktop, and
> so on. Again, I can't see why doing something as trivial as accessing a
> floppy - even if it's dud - should have such a major effect on the
> system. (I also think the XP system is less tolerant of the poor
> floppy.)
>
Remember that currently, computer = Turing Machine, i.e. literally one
instruction at a time, so a low level timing function can hold up everything
else. Whether a task manager always interprets that as actual CPU hogging
when it's not, I don't know without experimenting, but all redraws and
anything else that needs CPU time have to wait. I don't think the CPU is any
busier though, I think it's just waiting like everything else when low level
I/O access is held up.
Everyone who has responded so far has given good information. Taken
together, IMO they give a good picture of what's going on. A bit higher
level explanation might go thusly:
Being magnetic, floppy disks do lost their data over time as short as 6
months and as long as a year or so, depending on the care they receive in
storage and the condition of the floppy drive.
Back in the days of floppies & pre affordable hard drives, most
companies had a program of "refreshing" their floppies every 6 months or
thereabouts. Refreshing consisted of nothing but copying the data off the
drive, doing a Quick Format on it, and then copying the data back to the
floppy. Floppies would last several years that way as long as they were
stored somewhat reasonably away from heat, brght light (susnlight) and
anything magnetic like speakers. My collection of around 700 CP/M & DOS
floppies actually lasted long enough to finally be copied to hard disks and
external drives for backup archives. They're historcal records.
When a floppy starts to be formatted and begins taking forever (over a
couple minutes) without advancing it's a pretty good guess that the floppy
is bad. The OS makes several attempts to read the sectors (at least twice,
up to a hundred times or so) And then compares each of the reads, picking
the largest quantity of reads that are the same, and "assumes" that was a
good read and thus uses it. With 512k sectors that can get to be very time
consuming and a waste of time.
As someone mentioned, it's often best to use the command line for
formatting floppies for the extra control it provides.
There are DOS programs around that are meant to "recover" decaying
floppies. Mine seems to be lost in the archives somewhere; all I see left is
the WordStar to Word converter, meaning several others are hiding away from
me too.
The "recover floppy" program did a lot better and more efficient job than
anything you could do manually and was often surpsingly effectively. I guess
Google would be the best way to find it now.
As for locking up the sy
IMO it's never useful to try to check a floppy for bad sectors: Let a Full
Format do that for you; it'll mark out any bad sectors for you unless there
are too many of them or the ID area of the floppy is damaged, which is often
the case. Fgure out what the system lines should have for data and try
rewriting them. It might work, might now.
Probably the most effective way to gt data off a floppy that was really
important to me/us was to use a hex editor and completely bypass the OS.
Copy the data, less the system data sectors, to another location and try to
open that; often it'll open. If it's a text file that often works, but if
it's an executable, and doesn't work, you're out of luck with this method.
That's my 'IIRC' anyway from some years ago<g>. It all depends on how
important the data on the floppy is to you. If it's really important, time
is of the essence; floppies begin to degrade on the closer together inner
tracks and works its way outwards most of the time.
HTH,
Twayne`
That's it! Works well if you can get your hands on a copy of it.
HTH,
Twayne`
Dailysex, or is it spelled dyslexia, rules KO! (Dr[.] J.[ ]B.[ ]Davis)
No, everything slows to an unusable state on the '95 system when testing
the bad floppy. On the XP system, if I'm using the browser to access a
site that is being sluggish to respond, I can still use most other
functions without difficulty (email, explorer etc.). I can't say how
browser waiting would affect the '95 system, as it isn't networked, but
I don't _think_ it would slow it down as much as scanning the floppy
does.
(As to whether it's the CPU or a low level driver, I have no idea - I
just know the computer goes treacly. My main question is _why_; even '95
is a nominally multitasking system [yes I know multitasking is an
illusion on a Turing machine], so I don't see why.)
>
>One thing I read about bad floppies, is that it's worth just letting it retry
>up to 100 times overnight if need be, that it usually gets a read in the end
>if there's no scarring of the disk surface. Another thing I used to do that
[]
Sorry, I clearly didn't stress enough that this is purely an
intellectual puzzle: lots of people are being very kind and helping me
to recover data from a dud floppy. I'm not: I have a good floppy for the
data transfers I need to do. I'm just curious as to why, on the '95
system, _scanning_ the failing floppy seems to hog so much of the system
resources, and on the XP system, why once having had a "bad read" or
similar experience, it seems to screw up use of the (USB) floppy drive
for getting on for the remains of that session, even if I use the good
floppy.
--
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)
No, fortunately I'm not in the position of having lost any important
data; I'm just playing with the floppy for curiosity!
>
>Comment: It figures that XP will freak out and lock up over a bad
>floppy. XP is more unstable than Win98 in my opinion.
>
No, it's the opposite - I can still do anything _else_ - read email,
browse the web, etc. - fine; it's just the particular explorer window
that's accessing a: that more or less locks up. (And seems to have a
memory.) It behaves _very_ oddly: it accesses the floppy for a few
seconds, then _doesn't_ - even the light goes off - for a few seconds,
and this repeats many times. Very odd.
--
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)
>>Is it really the CPU time it's hogging? (Check in a good task manager..)
>>It might be the low level driver waiting and timing out and retrying
>>that takes all the time. Other parts of the system often have to wait
>>for low level driver accesses to complete, the same sort of thing shows
>>up with browsers trying to get remote data, etc.
>
> No, everything slows to an unusable state on the '95 system when testing
> the bad floppy. On the XP system, if I'm using the browser to access a
> site that is being sluggish to respond, I can still use most other
> functions without difficulty (email, explorer etc.). I can't say how
> browser waiting would affect the '95 system, as it isn't networked, but
> I don't _think_ it would slow it down as much as scanning the floppy
> does.
>
> (As to whether it's the CPU or a low level driver, I have no idea - I
> just know the computer goes treacly. My main question is _why_; even '95
> is a nominally multitasking system [yes I know multitasking is an
> illusion on a Turing machine], so I don't see why.)
>
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.
About the floppies themselves, I realise you were curious, not having actual
problem, I just mentioned what I usually mention if the subject comes up
because it worked for me, and better than all the complex things tried in
absense of the simple mecahnics of a cleaning wipe on the inner liner. (I
think stuff gets deposited there, and if it's then allowed to sit for a
while, it hardens enough to stick, so a bit of deliberate loosening seems in
order. I also assume a disk doing that isn't going to get any better so I
always salvage what's on it at that point.
==
Cheers, Tim Meddick, Peckham, London. :-)
"J. P. Gilliver (John)" <G6...@soft255.demon.co.uk> wrote in message
news:NWrMgIPW...@soft255.demon.co.uk...
> 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...
>
Yep, that could confirm it, even a closing window is a fairly intensive
graphical activity, if it goes immediately the CPU is ok, when it gets a
chance to do the deed.
The division of labour between demanding processes is on much smaller time
scales so you'd see every last redraw crawl painfully into being if the
constriction was available CPU time.
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
> 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
as they do in a similar make of drive. Some of the plastics fail in drives
after long exposure to come greases, especially if anything like cooking or
smoking fumes get onto them frequently. My instinct tells me you need to
eliminate physical causes before looking deeper at the software. But you'll
know more, for all I know thw drive might be new..
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.
[]
> 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
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.
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 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.**
> 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.**
>
I got nothing... except to try that idea of raw copy to good disk, then see
if they behave differently or not. If nothing at all can get bits off that
disk then you have all the answers you'll usefully get. Could try seeing if
simple ejection of a good disk, mid-read, does anything you wouldn't normally
expect when you do that.
> I had lunch today in a restaurant where the food was abdominal. - G4PKP's
> bienapropism list
Should have done it to the dulcet tones of A Small Lunch, by Pungent Stench.
Thpthpthp.. >:)