🚀 go-pugleaf

David Longley (David@longley.demon.co.uk) wrote:
: I've  had  a problem on a few machines (some IDE and  some  SCSI) 
: which  makes me suspect a virus. Scandisk reports that  it  can't 
: read  the last cluster on the drive .. I have ended up having  to 
: FDISK and reformat. I scanned with DR SOl and Nortion and neither 
: detected anything.. 

I see this quite often on systems with large disks partitioned into
two. I wouldn't personally trash a drive because of a trivial 
SCANDISK message: it's a very limited tool. Run something more
powerful like NDD as a diagnostic, but be careful if it actually
detects a possible problem.

--
David Harley
D_Harley@iname.com 
http://webworlds.co.uk/dharley/
"Opinions are free: advice is free: consultancy costs...."

I see a lot of partitions where the partition table and the boot sector
sector length appears to be either 1 or 2 cylinders longer than the actual
disk (as detected by the BIOS).

Perhaps this is a miscalculation by the Windows/DOS install routine.

I see this an awful lot when fix hdds (i.e. partition table data against
BIOS CHS values).

Example:

int 13h get disk info returns

995,31,63     (disk has 2007936 sectors)

but partition table says

128    6    0,1,1 - 996,31,63     63      2009889

and boot sector bpb.huge_sector_count = 2009889

or

128    6    0,1,1 - 997,31,63     63      2011905

and boot sector bpb.huge_sector_count = 2011905

Could it be that this disk has this problem and the disk has become full and
scandisk or DOS is trying to r/w these non-existent clusters (i.e. the last
or penultimate cylinder).

This may or may not be the source of the problem, but in any event I would
be interested to hear of anyone who knows why this happens (and it happens
an awful lot).

Kindest regards,

Jem

David Harley wrote in message <7a0u7p$vt$1@bliss.lif.icnet.uk>...
>David Longley (David@longley.demon.co.uk) wrote:
>: I've  had  a problem on a few machines (some IDE and  some  SCSI)
>: which  makes me suspect a virus. Scandisk reports that  it  can't
>: read  the last cluster on the drive .. I have ended up having  to
>: FDISK and reformat. I scanned with DR SOl and Nortion and neither
>: detected anything..
>
>I see this quite often on systems with large disks partitioned into
>two. I wouldn't personally trash a drive because of a trivial
>SCANDISK message: it's a very limited tool. Run something more
>powerful like NDD as a diagnostic, but be careful if it actually
>detects a possible problem.
>
>--
>David Harley
>D_Harley@iname.com
>http://webworlds.co.uk/dharley/
>"Opinions are free: advice is free: consultancy costs...."
>

In article <36c419fe.0@glitch.nildram.co.uk>,
	"Jeremy Brooks" <jem@datasecurity.co.uk> writes:
> I see a lot of partitions where the partition table and the boot sector
> sector length appears to be either 1 or 2 cylinders longer than the actual
> disk (as detected by the BIOS).
> 
> Perhaps this is a miscalculation by the Windows/DOS install routine.
> 
> I see this an awful lot when fix hdds (i.e. partition table data against
> BIOS CHS values).
> 
> Example:
> 
> int 13h get disk info returns
> 
> 995,31,63     (disk has 2007936 sectors)
> 
> but partition table says
> 
> 128    6    0,1,1 - 996,31,63     63      2009889
> 
> and boot sector bpb.huge_sector_count = 2009889
> 
> or
> 
> 128    6    0,1,1 - 997,31,63     63      2011905
> 
> and boot sector bpb.huge_sector_count = 2011905
> 
> Could it be that this disk has this problem and the disk has become full and
> scandisk or DOS is trying to r/w these non-existent clusters (i.e. the last
> or penultimate cylinder).
> 
> This may or may not be the source of the problem, but in any event I would
> be interested to hear of anyone who knows why this happens (and it happens
> an awful lot).

  There *used* to be a system where drives had a 'spare' cylinder for
various purposes.  This *could* be the source of this problem.

  Regards,
     Harry.

Jeremy Brooks (jem@datasecurity.co.uk) wrote:

[stuff with big numbers snipped ;-)]

: Could it be that this disk has this problem and the disk has become full and
: scandisk or DOS is trying to r/w these non-existent clusters (i.e. the last
: or penultimate cylinder).

I haven't been seeing this in a disk full situation, though: what
appears to happen is that an often-trivial system crash forces a scandisk 
run on restart, as you'd expect, and the user lets scandisk do its famous
impersonation of a physical check on the disk, whereupon the message 
pops up and they call for help. Which seems more or less consistent with 
your analysis, nonetheless. FWIW, I'm seeing it on brand new systems 
with copious disk space.

--
David Harley
D_Harley@iname.com 
http://webworlds.co.uk/dharley/
"Opinions are free: advice is free: consultancy costs...."

"Jeremy Brooks" <jem@datasecurity.co.uk> wrote:

>I see a lot of partitions where the partition table and the boot sector
>sector length appears to be either 1 or 2 cylinders longer than the actual
>disk (as detected by the BIOS).
>
>Perhaps this is a miscalculation by the Windows/DOS install routine.
>
>I see this an awful lot when fix hdds (i.e. partition table data against
>BIOS CHS values).
>
>Example:
>
>int 13h get disk info returns
>
>995,31,63     (disk has 2007936 sectors)
>
>but partition table says
>
>128    6    0,1,1 - 996,31,63     63      2009889
>
>and boot sector bpb.huge_sector_count = 2009889
>
>or
>
>128    6    0,1,1 - 997,31,63     63      2011905
>
>and boot sector bpb.huge_sector_count = 2011905
>
>Could it be that this disk has this problem and the disk has become full and
>scandisk or DOS is trying to r/w these non-existent clusters (i.e. the last
>or penultimate cylinder).
>
>This may or may not be the source of the problem, but in any event I would
>be interested to hear of anyone who knows why this happens (and it happens
>an awful lot).
>
>Kindest regards,
>
>Jem

I've never noticed that.

On this computer the two agree: 620,63,63. The BIOS params are
622,64,63, so there is one cylinder of slack. 

FDISK calls int 13 ah = 8 (or the equivalent extended function if for
LBA) before it fills in the partition table, so it would seem to be
most likely a bug in some version of FDISK. I'll have to keep an eye
out for that one.

Bob

Tarkan Yetiser wrote in message ...
>In article <36c4cbf1.1157420@news.mindspring.com>, rgreen@avana.net
>says...
>> FDISK calls int 13 ah = 8 (or the equivalent extended function if for
>> LBA) before it fills in the partition table, so it would seem to be
>> most likely a bug in some version of FDISK. I'll have to keep an eye
>> out for that one.
>
>FDISK is quite buggy actually. Have you ever seen it report 120% usage
>for a partition? Just create a non-DOS partition at the front of the
>disk, and see what happens;-)


Hee hee.

FDISK is THE crappest program I have ever used.

The interface is like a first school readln/writeln exercise program.

Nearly as bad as EDLIN. Remember that one? :-(

Jem

p.s. anyone know what FDISK error 120 is?

TIA

In alt.comp.virus Jeremy Brooks <jem@datasecurity.co.uk> wrote:
[snip]
> FDISK is THE crappest program I have ever used.

> The interface is like a first school readln/writeln exercise program.

> Nearly as bad as EDLIN. Remember that one? :-(

   Sure.  I swore at it; my advisor swore by it.  Had its good points, but I
liked another editor better: 

   DEBUG

   Prettier output.

> p.s. anyone know what FDISK error 120 is?

   Not offhand, but I'm looking at the FDISK binary now... for posting in
another thread.

   -BPB

Tarkan Yetiser (tark@vds.net) wrote:

: Due to an inconsistency in the BPB. For example, if you take an image of 
: an 8 gig drive, storing only the used clusters, and then splat that onto 
: a 6 gig drive (it'll fit if data was less than that), and forget to 
: update the BPB properly, SCANDISK will go bananas trying to access the 
: last cluster. 

Yes, I suspect that all the machines I've seen this problem on were
Ghosted: a disparity between the target disk size and the original
image could certainly be the cause, in this case.

--
David Harley
D_Harley@iname.com 
http://webworlds.co.uk/dharley/
"Opinions are free: advice is free: consultancy costs...."

Harry Broomhall wrote in message <7a1g6p$92a$1@quince.news.easynet.net>...
>  There *used* to be a system where drives had a 'spare' cylinder for
>various purposes.  This *could* be the source of this problem.


I think that would be the space used to reallocate bad clusters.

Kev

In alt.comp.virus Kevin M <kevmit@flash.net> wrote:

> Harry Broomhall wrote in message <7a1g6p$92a$1@quince.news.easynet.net>...
>>  There *used* to be a system where drives had a 'spare' cylinder for
>>various purposes.  This *could* be the source of this problem.


> I think that would be the space used to reallocate bad clusters.

   Different thing: that's extra sectors per track, not the extra cylinder at
the end of the drive.  Unless things have changed, but I doubt it: seeking all
the way to the end of the drive sounds prohibitive performance-wise.

   -BPB

In article <welz2.8152$Ge3.32072890@news.itd.umich.edu>, bpb@umich.edu wrote:
>In alt.comp.virus Kevin M <kevmit@flash.net> wrote:
>
>> Harry Broomhall wrote in message <7a1g6p$92a$1@quince.news.easynet.net>...
>>>  There *used* to be a system where drives had a 'spare' cylinder for
>>>various purposes.  This *could* be the source of this problem.
>
>
>> I think that would be the space used to reallocate bad clusters.
>
>   Different thing: that's extra sectors per track, not the extra cylinder at
>the end of the drive.  Unless things have changed, but I doubt it: seeking all
>the way to the end of the drive sounds prohibitive performance-wise.

Reallocation is quite complex actually, and variable from manufacturer to 
manufacturer.  When a sector goes bad, the whole track is shifted and when it 
is not possible, usually reallocated from the spare track pool. This can lead 
to very significant slow downs in drive access anyway. But as you say, these 
have nothing to do with the last track (which can actually not be the last 
one, far from it) and is totally invisible at the application / bios level.

I think the explanations with invalid fdisk values could have been the correct 
answer, as someone said earlier.

Pierre


Pierre Vandevenne
www.datarescue.com, the home of the IDA Pro Disassembler
Version 3.8 now available - www.datarescue.com/idanew.htm

In article <welz2.8152$Ge3.32072890@news.itd.umich.edu>, Bruce P.
Burrell <bpb@umich.edu> writes
>In alt.comp.virus Kevin M <kevmit@flash.net> wrote:
>
>> Harry Broomhall wrote in message <7a1g6p$92a$1@quince.news.easynet.net>...
>>>  There *used* to be a system where drives had a 'spare' cylinder for
>>>various purposes.  This *could* be the source of this problem.
>
>
>> I think that would be the space used to reallocate bad clusters.
>
>   Different thing: that's extra sectors per track, not the extra cylinder at
>the end of the drive.  Unless things have changed, but I doubt it: seeking all
>the way to the end of the drive sounds prohibitive performance-wise.
>
>   -BPB
>
I didn't read the rest of this thread, but here's my four penneth
anyway: I know that certain disk imaging programs cause this problem. I
used to work for a company who used Ghost to pre-install Win95/98. When
Ghost copied the image to a drive (or partition) over 8GB, Scandisk
would report not being able to read the last cluster. An FDISK and
FORMAT resolved this. They used to split the drives into 2 partitions
until Ghost released a new version which fixed this bug.
-- 
Paul S Bulley
mailto:paul@rowlands-rise.demon.co.uk