w2k chkdsk "windows replaced bad clusters in file" question

  • Thread starter Thread starter jhigbee
  • Start date Start date
J

jhigbee

When Windows 2000 checkdisk chkdsk reports "windows replaced bad
clusters in file" does that mean that data was lost or not?

I got the message on while doing a chkdsk /f /r on an 80GB supposedly
refurbished Seagate ST380011A hard drive - on three large ISO type
files.

However when chkdsk completed it said there were no bad sectors found.

So, does this mean that:

Option 1: the redunancy of ntfs most likely allowed the drive's "SMART"
functionality to a.) not have lost any data in the first place because
of the redunancy of ntfs, and b.) that the starting to flake out
sections of the ISO files was reallocated to a different sector;

or, option 2: that because there's no good documentation what the
chkdsk message "windows replaced bad clusters in file" really means who
knows - maybe the three large ISO files which it reported that message
for really do now have some corruption.

On a side note I've been testing spinrite, but it's so very slow I've
almost thought about setting up a spare computer in another room just
for the sole purpose of running spinrite on it (and so that I won't
have to listen to a computer while I attempt to sleep).
 
When Windows 2000 checkdisk chkdsk reports "windows replaced bad
clusters in file" does that mean that data was lost or not?

I got the message on while doing a chkdsk /f /r on an 80GB supposedly
refurbished Seagate ST380011A hard drive - on three large ISO type
files.

However when chkdsk completed it said there were no bad sectors found.

So, does this mean that:
Click to expand...

Harddrives have "spare" sectors in reserve that the drive's electronics
use to swap out with sectors that go bad. This is supposed to happen
without your noticing and the integrity of the data would be preserved (if
the drive electronics can't verify a write they use a spare sector and add
the problematic sector to the grown defect list) but sometimes it happens
during a chkdsk (where the data is already in a sector found to be bad) in
which case the data may have been damaged.

I'd definitely watch the SMART status and see if the number of replaced
sectors is increasing. If so, replace the failing drive. The fact that
it was a refurbished drive doesn't bode well.
 
When Windows 2000 checkdisk chkdsk reports "windows replaced bad
clusters in file" does that mean that data was lost or not?

I got the message on while doing a chkdsk /f /r on an 80GB supposedly
refurbished Seagate ST380011A hard drive - on three large ISO type
files.

However when chkdsk completed it said there were no bad sectors found.

So, does this mean that:

Option 1: the redunancy of ntfs most likely allowed the drive's "SMART"
functionality to a.) not have lost any data in the first place because
of the redunancy of ntfs, and b.) that the starting to flake out
sections of the ISO files was reallocated to a different sector;

or, option 2: that because there's no good documentation what the
chkdsk message "windows replaced bad clusters in file" really means who
knows - maybe the three large ISO files which it reported that message
for really do now have some corruption.

On a side note I've been testing spinrite, but it's so very slow I've
almost thought about setting up a spare computer in another room just
for the sole purpose of running spinrite on it (and so that I won't
have to listen to a computer while I attempt to sleep).
Click to expand...
Supposedly Refurbished ?. What the hell does that mean ?. Has someone
cleaned it, and reformatted it ?. Download the hard drive test tools from
Seagate, and test the drive. you don`t want to lose your (valuable ?.) data
do you ?.
best wishes..OJ
 
Google groups on "windows replaced bad clusters in file" comes up with clues.

Sometimes chkdsk reports bad sectors, sometimes not.
Check for errors in event viewer and drive diagnostics.

Some people are getting this error only on pagefile.sys
and compressed folders like system32\dllcache.
That suggests there is a bug in chkdsk,
perhaps it is reading out-of-bounds sectors.
 
When Windows 2000 checkdisk chkdsk reports "windows replaced bad
clusters in file" does that mean that data was lost or not?

I got the message on while doing a chkdsk /f /r on an 80GB supposedly
refurbished Seagate ST380011A hard drive - on three large ISO type
files.

However when chkdsk completed it said there were no bad sectors found.

So, does this mean that:

Option 1: the redunancy of ntfs most likely allowed the drive's "SMART"
functionality to a.) not have lost any data in the first place because
of the redunancy of ntfs, and b.) that the starting to flake out
sections of the ISO files was reallocated to a different sector;

or, option 2: that because there's no good documentation what the
chkdsk message "windows replaced bad clusters in file" really means who
knows - maybe the three large ISO files which it reported that message
for really do now have some corruption.

On a side note I've been testing spinrite, but it's so very slow I've
almost thought about setting up a spare computer in another room just
for the sole purpose of running spinrite on it (and so that I won't
have to listen to a computer while I attempt to sleep).
Click to expand...

Slightly OT, but I had a similar problem with ISO files and chkdsk. I
didn't realise at the time that when you create an ISO, the file it
creates can be very fragmented. I was copying and moving these 4Gb
'files' around on the hard drive, then suddenly the hard drive stopped
responding. Not surprising really, given the processing power required
to shift huge fragmented files around. Stupidly I rebooted, and chkdsk
started up. My index was damaged, and I made the mistake of letting
chkdsk 'fix' the problem. After about 24 hours, I was left with an
unintelligible mess. Small files had been joined together into one big
file, mp3's not joined together were all stripped of their leading 32k
(info tags), the 32k segments all left on the drive, some files just
plain gone, and all files were renamed to long meaningless strings. I
had to look at every one in turn to see what it was and whether I could
fix it.

If you can copy or recover any vital files to another drive before using
chkdsk I would recommend doing so.
 
aleX said:
Slightly OT, but I had a similar problem with ISO files and chkdsk. I
didn't realise at the time that when you create an ISO, the file it
creates can be very fragmented. I was copying and moving these 4Gb
'files' around on the hard drive, then suddenly the hard drive stopped
responding. Not surprising really, given the processing power required
to shift huge fragmented files around.
Click to expand...

That is just plain wrong. Fragmented files
have no effect on processing power at all.
 
Rod said:
That is just plain wrong. Fragmented files
have no effect on processing power at all.
Click to expand...

Thanks for letting me know, I won't erroneously describe it again.

I assumed that the system would need to keep track of where each
'fragment' was, rather than just a start and end point for a contiguous
file, hence take far longer. This probably isn't the case though, I'm no
expert, or anything approaching. What I do know is that chkdsk destroyed
a lot of the files on my drive, admittedly after I stupidly restarted
the machine when it may still have been processing.
 
aleX said:
Rod Speed wrote
Click to expand...
Thanks for letting me know, I won't erroneously describe it again.
Click to expand...
I assumed that the system would need to keep track of where each
'fragment' was, rather than just a start and end point for a contiguous file,
Yes.

hence take far longer.
Click to expand...

The effort required to do that is completely trivial processing power wise.
This probably isn't the case though, I'm no expert, or anything approaching.
What I do know is that chkdsk destroyed a lot of the files on my drive,
admittedly after I stupidly restarted the machine when it may still have been
processing.
Click to expand...

Yeah, tho it would have stalled for some other reason.

It certainly wouldnt have been due to fragmentation.
 
Rod Speed said:
That is just plain wrong. Fragmented files
have no effect on processing power at all.
Click to expand...

I would agree, but, under task manager, CPU usage shows Defrag hitting the
upper limits.

-a|ex
 
I would agree, but, under task manager, CPU usage shows Defrag hitting the
upper limits.
Click to expand...

Irrelevant. Thats just the extensive moving of
files around to get rid of the fragmentation.

You'd get the same result moving
unfragmented files around as much too.
 
Back
Top