No 98SE 'AutoScan' options

"Bill Blanton" wrote in message
...
|
| "PCR" wrote in message
...
|
| "Bill Blanton" wrote in message
| ...
| | "PCR" wrote in message
| ...
|
| | ...........Quote...................
| | This info is from an old KB article
|
| | The Clean Shutdown and Hard Disk Error bits are the two
low-order bits
| | of the FAT
| | entry for cluster 1.
|
| | The KB author says "the two low-order bits", but that isn't right.
| | The MS FAT spec defines it correctly-
| |
| | quote
| | For FAT16 and FAT32, the file system driver may use the high two
bits of
| | the FAT[1] entry for dirty volume flags
| | /quote
| |
| |
| | "high two bits", not "two low order bits". FAT32 only uses 28 bits
| | for cluster entries so it will be bit-26 and bit-27 of the dword
FAT[1}
| | entry.
|
| It's the two high-order (or rightmost) bits of a double-word, then.

Oops... High-order is LEFTMOST
Low-order is RIGHTMOST

|
| Not the high order bits of the dword,, the high order bits of the 28
| bit "subthing". There's no name for that, afaik.. It's a
WordByteNybble.

Huh? The Badour artiicle said...
"the two low-order bits of the FAT entry for cluster 1".
....This would be the rightmost two bits.

Your MS FAT spec lit said...
"the file system driver may use the high two bits of the FAT[1] entry".
....This would be the leftmost two bits.

|
| The intel little endian architecture stores bytes "backwards", but
| not the bits within the bytes. Dword 0x12345678 would be stored in
| memory as 0x78 0x56 0x34 0x12, if looking at it from a "low to high"
| address point of view. (and is naturally carried over to HD storage)

Well... NATURALLY, one must know what one is speaking of when one says
low/high-order. Is it pre-storage/post-retrieval or is it the thing as
stored? As neither yours nor Badour's article states it explicitly, it
must be assumed they are speaking of the pre-storage/post-retrieval
DWORD. Therefore...

| Considering dword 11111111 11111111 11111111 01111111 the high order

The bit you have turned off there is the high-order (leftmost) bit of
the pre-storage/post-retrieval DWORD. Therefore, your MS FAT spec lit
was correct, if you are depicting that DWORD correctly. I think a DWORD
has 8 bytes.

|
| Considering dword 11111111 11111111 11111111 01111111 the high order
| bit (bit-31) is only one clear. If only refering to 28-bits, it would
| look like this, with the high order bit cleared-
| 11111111 11111111 11111111 11110111.
|
| Using the term "right" or "left" just confuses the already insane!

High-order is Leftmost or Most Significant (greatest value).
Low-order is Rightmost or Least Significant (least value).

|
|
| And I suppose it applies separately for each partition in the system
known
| to Windows.
|
| For each volume ;-). FAT16 and FAT32, but not NT-based systems. They
moved
| it to the boot sector somewheres..

Each partition OR volume makes sense, as I have seen the Auto-Scandisk
operate upon Cartition, followed by G:volume, which holds my OE Store.
That is not the one/only volume of the Extended Partition, but it is the
only one Scandisk may go for.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Kentiguous" wrote in message
...
| PCR wrote :
| "Kentiguous" wrote in message
| ...
| | PCR wrote :
| ...those were my settings. NOW, I have made the second to be "Prompt"
| as
| well. In fact, as a punishment to me, I have changed every single one
| of
| them in that section to "Prompt", where formerly it was only the last
| one...
|
| LostClust = Prompt ; Lost clusters
|
| Boot_Sector = Prompt ; Damaged boot sector on DoubleSpace drive
| FSInfo_Sector = Prompt ; Incorrect free space count
| Invalid_MDFAT = Prompt ; Invalid MDFAT entries
| DS_Crosslinks = Prompt ; Internal (MDFAT-level) crosslinks
| DS_LostClust = Prompt ; Internal lost clusters
| DS_Signatures = Prompt ; Missing DoubleSpace volume signatures
| Mismatch_FAT = Prompt ; Mismatched FATs on non-DoubleSpace drives
| Bad_Clusters = Prompt ; Physical damage or decompression errors
|
| There are other settings ("Bad_Entries", "Okay_Entries", "Bad_Chain",
| "Crosslinks", "LabelCheck", "LfnCheck", "SpaceCheck", etc.) that you
| may want to alter, too. I'd suggest going through SCANDISK.INI
| 'with a fine-tooth comb', in order to obtain the behaviour that you
| desire.

My fine-tooth comb is full of gook. However, except for the HDD crash of
2001 which is less/less vivid to me, nothing horrible has turned up in
Scandisk.log. So, I've still got time. Do not tell cquirke I haven't
gotten to it, yet, though! I DID get to it, (but quit before I was
done).

WELL... let me see what yours looks like.

|
| | There are no references to Scandisk in either IO.SYS or
COMMAND.COM,
| | in Win98SE. WIN.COM is a DOS executable file.
|
| That's odd. Did you see my quote of Badour...?...
|
| ...elsewhere in this thread.
|
| I did; then I fired-up my hex editor to re-check the results that I
| posted, above. I guess Ron's info. was Win95 OSR 2.x specific;
| but, I have no easy way of verifying that.

That is still odd. Let me read the article again...

.......Quote................
OSR2 includes versions of the Io.sys and Win.com files that check the
Clean Shutdown and Hard Disk Error bits in the Virtual File Allocation
Table (VFAT) during startup. If either of these bits is turned on (that
is, cleared to 0) on any drive present in real mode, you are prompted to
run ScanDisk
.......EOQ...................

IO.sys is DOS. WIN.com is Windows. OSR2 is... ???. However, we do know
the mechanism that Auto-runs Scandisk still does exist.

|
| | | | scandisk /ALL /NOSUMMARY
| | | | if not errorlevel 1 goto scend2
| | | | echo Errors found! Press a key to re-scan/fix local
drive(s)...
| | | | pausenul
| | | | scandisk /ALL
| | | | :scend2
| | |
| | | I don't like the looks of that. The second run will not find
any
| | | errors.
| | |
| | | Yes, it will (see below).
| |
| | OK.
| |
| | |
| | | The first run did not record it's summary. (It may be the
summary
|
| | | & the
| | | error report are two different things, though, not sure.)
| | |
| | | They are two different things; but even if they weren't, the
| | | non-creation (or deletion) of SCANDISK.LOG will not affect
| | | Scandisk's
| | | ability to detect subsequent errors.
| |
| | OK, they're different. STILL, the second run will not find the
| | errors
| | that were fixed in the first run. Therefore, it is important to
| | select
| | "append" for the .log, not "overwrite", if you are going to run it
| | twice
| | in a row!
| |
| | The first run will not fix the errors, here (hence, the need for
the
| | second run). If the first run did fix the errors, it would be
rather
| | difficult for Scandisk to fix them, during the second run, if they
no
| | longer existed. g Logging is irrelevant WRT Scandisk's ability to
| | fix
| | errors. You can use "SaveLog=Off", in SCANDISK.INI to disable
| | logging.
|
| I thought/think it is "/CHECKONLY" that does that, not "/NOSUMMARY".
|
| Try it. One can't argue with 'real-world' results.

C:\scandisk/?
For information about the command-line parameters supported by
ScanDisk for Windows, look up 'checking for errors, in disks' in
the Windows Help index. Then view the topic 'Checking your disk
for errors every time your computer starts.'

....There is no real info about it where DOS instructs one to look. Be
more descriptive of your "real-world results". You used "/NOSUMMARY", &
I'm sure you got no summary. What makes you sure it did no fix, which I
think /CHECKONLY would be for? What, if anything, was in Scandisk.log
after a /NOSUMMARY run?

|
| Ken
|
| --
| Remove the '4' to reply via email

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"PCR" wrote in message ...
"Bill Blanton" wrote in message
...
|
| "PCR" wrote in message
...


| | "high two bits", not "two low order bits". FAT32 only uses 28 bits
| | for cluster entries so it will be bit-26 and bit-27 of the dword FAT[1}
| | entry.
|
| It's the two high-order (or rightmost) bits of a double-word, then.

Oops... High-order is LEFTMOST
Low-order is RIGHTMOST

Right. Looking at the "whole" data type.

| Not the high order bits of the dword,, the high order bits of the 28
| bit "subthing".


Huh? The Badour artiicle said...
"the two low-order bits of the FAT entry for cluster 1".
...This would be the rightmost two bits.

Your MS FAT spec lit said...
"the file system driver may use the high two bits of the FAT[1] entry".
...This would be the leftmost two bits.

What I was pointing out was that it is not the high-order bits of
the 32-bit dword that holds the 28-bit cluster value. It is bit-27
of the dword.

| The intel little endian architecture stores bytes "backwards", but
| not the bits within the bytes. Dword 0x12345678 would be stored in
| memory as 0x78 0x56 0x34 0x12, if looking at it from a "low to high"
| address point of view. (and is naturally carried over to HD storage)

Well... NATURALLY, one must know what one is speaking of when one says
low/high-order. Is it pre-storage/post-retrieval or is it the thing as
stored? As neither yours nor Badour's article states it explicitly, it
must be assumed they are speaking of the pre-storage/post-retrieval
DWORD. Therefore...


"High-order" is high order either way. :-\


| Considering dword 11111111 11111111 11111111 01111111 the high order

The bit you have turned off there is the high-order (leftmost) bit of
the pre-storage/post-retrieval DWORD.

"In storage". In a CPU register the high-order bit of a dword would
be here- 01111111111111111111111111111111 Those four bytes moved to
memory will be as above paragraph.


Therefore, your MS FAT spec lit
was correct, if you are depicting that DWORD correctly. I think a DWORD
has 8 bytes.


Speaking of intel x86 architecture-
8 bits in a byte.
2 bytes in a word.
2 words in a dword.

"Bill Blanton" wrote in message
...
|
| "PCR" wrote in message
...
| "Bill Blanton" wrote in message
| ...
| |
| | "PCR" wrote in message
| ...
|
|
| | | "high two bits", not "two low order bits". FAT32 only uses 28
bits
| | | for cluster entries so it will be bit-26 and bit-27 of the
dword FAT[1}
| | | entry.

Yikes. I missed this last read (or last couple of them). Then, the
Badour article begins to look good...

"the two low-order bits of the FAT entry for cluster 1".

Bit's 26 & 27, counting from zero, turn out to be that.

| |
| | It's the two high-order (or rightmost) bits of a double-word,
then.
|
| Oops... High-order is LEFTMOST
| Low-order is RIGHTMOST
|
| Right. Looking at the "whole" data type.

OK.

|
| | Not the high order bits of the dword,, the high order bits of the
28
| | bit "subthing".

OK.

|
|
| Huh? The Badour artiicle said...
| "the two low-order bits of the FAT entry for cluster 1".
| ...This would be the rightmost two bits.
|
| Your MS FAT spec lit said...
| "the file system driver may use the high two bits of the FAT[1]
entry".
| ...This would be the leftmost two bits.
|
| What I was pointing out was that it is not the high-order bits of
| the 32-bit dword that holds the 28-bit cluster value. It is bit-27
| of the dword.

OK. I get it now.

|
| | The intel little endian architecture stores bytes "backwards", but
| | not the bits within the bytes. Dword 0x12345678 would be stored in
| | memory as 0x78 0x56 0x34 0x12, if looking at it from a "low to
high"
| | address point of view. (and is naturally carried over to HD
storage)
|
| Well... NATURALLY, one must know what one is speaking of when one
says
| low/high-order. Is it pre-storage/post-retrieval or is it the thing
as
| stored? As neither yours nor Badour's article states it explicitly,
it
| must be assumed they are speaking of the pre-storage/post-retrieval
| DWORD. Therefore...
|
|
| "High-order" is high order either way. :-\

High-order is the leftmost bits. If they are stored left-to-right, then
they are no longer the high-order bits, until they are read back into a
register.

|
|
| | Considering dword 11111111 11111111 11111111 01111111 the high
order
|
| The bit you have turned off there is the high-order (leftmost) bit
of
| the pre-storage/post-retrieval DWORD.
|
| "In storage". In a CPU register the high-order bit of a dword would
| be here- 01111111111111111111111111111111 Those four bytes moved to
| memory will be as above paragraph.

That is what I mean by the pre-storage/post-retrieval value, which
normally one would presume to be all that is spoke of. Once this is
stored, that off bit (0) will no longer be the highest-order bit.

|
|
| Therefore, your MS FAT spec lit
| was correct, if you are depicting that DWORD correctly. I think a
DWORD
| has 8 bytes.
|
|
| Speaking of intel x86 architecture-
| 8 bits in a byte.
| 2 bytes in a word.
| 2 words in a dword.

OK.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

PCR or anyone else --- Where is cquirke? I definately miss his unique way of
analyzing situations. Please don't inform me that he has jumped ship to
another newsgroup. If he has I understand but will be saddened because it
will be a great loss since Chris has been a great asset to this group, imo.

"PCR" wrote in message
...
: "Kentiguous" wrote in message
: ...
: | PCR wrote :
: | "Kentiguous" wrote in message
: | ...
: | | PCR wrote :
: | ...those were my settings. NOW, I have made the second to be "Prompt"
: | as
: | well. In fact, as a punishment to me, I have changed every single one
: | of
: | them in that section to "Prompt", where formerly it was only the last
: | one...
: |
: | LostClust = Prompt ; Lost clusters
: |
: | Boot_Sector = Prompt ; Damaged boot sector on DoubleSpace drive
: | FSInfo_Sector = Prompt ; Incorrect free space count
: | Invalid_MDFAT = Prompt ; Invalid MDFAT entries
: | DS_Crosslinks = Prompt ; Internal (MDFAT-level) crosslinks
: | DS_LostClust = Prompt ; Internal lost clusters
: | DS_Signatures = Prompt ; Missing DoubleSpace volume signatures
: | Mismatch_FAT = Prompt ; Mismatched FATs on non-DoubleSpace drives
: | Bad_Clusters = Prompt ; Physical damage or decompression errors
: |
: | There are other settings ("Bad_Entries", "Okay_Entries", "Bad_Chain",
: | "Crosslinks", "LabelCheck", "LfnCheck", "SpaceCheck", etc.) that you
: | may want to alter, too. I'd suggest going through SCANDISK.INI
: | 'with a fine-tooth comb', in order to obtain the behaviour that you
: | desire.
:
: My fine-tooth comb is full of gook. However, except for the HDD crash of
: 2001 which is less/less vivid to me, nothing horrible has turned up in
: Scandisk.log. So, I've still got time. Do not tell cquirke I haven't
: gotten to it, yet, though! I DID get to it, (but quit before I was
: done).
:
: WELL... let me see what yours looks like.
:
: |
: | | There are no references to Scandisk in either IO.SYS or
: COMMAND.COM,
: | | in Win98SE. WIN.COM is a DOS executable file.
: |
: | That's odd. Did you see my quote of Badour...?...
: |
: | ...elsewhere in this thread.
: |
: | I did; then I fired-up my hex editor to re-check the results that I
: | posted, above. I guess Ron's info. was Win95 OSR 2.x specific;
: | but, I have no easy way of verifying that.
:
: That is still odd. Let me read the article again...
:
: ......Quote................
: OSR2 includes versions of the Io.sys and Win.com files that check the
: Clean Shutdown and Hard Disk Error bits in the Virtual File Allocation
: Table (VFAT) during startup. If either of these bits is turned on (that
: is, cleared to 0) on any drive present in real mode, you are prompted to
: run ScanDisk
: ......EOQ...................
:
: IO.sys is DOS. WIN.com is Windows. OSR2 is... ???. However, we do know
: the mechanism that Auto-runs Scandisk still does exist.
:
: |
: | | | | scandisk /ALL /NOSUMMARY
: | | | | if not errorlevel 1 goto scend2
: | | | | echo Errors found! Press a key to re-scan/fix local
: drive(s)...
: | | | | pausenul
: | | | | scandisk /ALL
: | | | | :scend2
: | | |
: | | | I don't like the looks of that. The second run will not find
: any
: | | | errors.
: | | |
: | | | Yes, it will (see below).
: | |
: | | OK.
: | |
: | | |
: | | | The first run did not record it's summary. (It may be the
: summary
: |
: | | | & the
: | | | error report are two different things, though, not sure.)
: | | |
: | | | They are two different things; but even if they weren't, the
: | | | non-creation (or deletion) of SCANDISK.LOG will not affect
: | | | Scandisk's
: | | | ability to detect subsequent errors.
: | |
: | | OK, they're different. STILL, the second run will not find the
: | | errors
: | | that were fixed in the first run. Therefore, it is important to
: | | select
: | | "append" for the .log, not "overwrite", if you are going to run it
: | | twice
: | | in a row!
: | |
: | | The first run will not fix the errors, here (hence, the need for
: the
: | | second run). If the first run did fix the errors, it would be
: rather
: | | difficult for Scandisk to fix them, during the second run, if they
: no
: | | longer existed. g Logging is irrelevant WRT Scandisk's ability to
: | | fix
: | | errors. You can use "SaveLog=Off", in SCANDISK.INI to disable
: | | logging.
: |
: | I thought/think it is "/CHECKONLY" that does that, not "/NOSUMMARY".
: |
: | Try it. One can't argue with 'real-world' results.
:
: C:\scandisk/?
: For information about the command-line parameters supported by
: ScanDisk for Windows, look up 'checking for errors, in disks' in
: the Windows Help index. Then view the topic 'Checking your disk
: for errors every time your computer starts.'
:
: ...There is no real info about it where DOS instructs one to look. Be
: more descriptive of your "real-world results". You used "/NOSUMMARY", &
: I'm sure you got no summary. What makes you sure it did no fix, which I
: think /CHECKONLY would be for? What, if anything, was in Scandisk.log
: after a /NOSUMMARY run?
:
: |
: | Ken
: |
: | --
: | Remove the '4' to reply via email
:
: --
: Thanks or Good Luck,
: There may be humor in this post, and,
: Naturally, you will not sue,
: should things get worse after this,
: PCR
:
:
:

"PCR" wrote in message ...
"Bill Blanton" wrote in message
...
|
| "PCR" wrote in message
...
| "Bill Blanton" wrote in message
| ...
| |
| | "PCR" wrote in message
| ...
|
|
| | | "high two bits", not "two low order bits". FAT32 only uses 28
bits
| | | for cluster entries so it will be bit-26 and bit-27 of the
dword FAT[1}
| | | entry.

Yikes. I missed this last read (or last couple of them). Then, the
Badour article begins to look good...

"the two low-order bits of the FAT entry for cluster 1".

Bit's 26 & 27, counting from zero, turn out to be that.

The low order bit (LSBit) is always bit-0. ("on the right" (x), if
written in "readable form") 111111x. The high order bit (MSBit) is
of course width-1. Bit-7 in an 8 bit byte.


| What I was pointing out was that it is not the high-order bits of
| the 32-bit dword that holds the 28-bit cluster value. It is bit-27
| of the dword.

OK. I get it now.

!


| Well... NATURALLY, one must know what one is speaking of when one
says
| low/high-order. Is it pre-storage/post-retrieval or is it the thing
as
| stored? As neither yours nor Badour's article states it explicitly,
it
| must be assumed they are speaking of the pre-storage/post-retrieval
| DWORD. Therefore...
|
|
| "High-order" is high order either way. :-\

High-order is the leftmost bits. If they are stored left-to-right, then
they are no longer the high-order bits, until they are read back into a
register.

No matter how you mix up the bits the high-order bit is always the MSBit.
That's why I said refering to "Left" and "Right" acn confuse the issue.
Unless you're looking at the "whole", as we humans like to look at numbers.
(maybe that's why they came up with the terms "high and low" in the
first place?. "Left and "right" don't really cut it)


Again, after the intel processor pokes a dword in memory, such as
| | dword 11111111 11111111 11111111 01111111 the high order
...bit is where the zero is. The high order -byte- (or MSB) of the
dword would be 01111111.



|
| The bit you have turned off there is the high-order (leftmost) bit
of
| the pre-storage/post-retrieval DWORD.
|
| "In storage". In a CPU register the high-order bit of a dword would
| be here- 01111111111111111111111111111111 Those four bytes moved to
| memory will be as above paragraph.

That is what I mean by the pre-storage/post-retrieval value, which
normally one would presume to be all that is spoke of. Once this is
stored, that off bit (0) will no longer be the highest-order bit.

The "high order bit" is always the high order bit :-| and doesn't change
if you store it backwards. It "looks" like it's in a different position
if you do a memory dump to screen, or look at a larger than byte value
in other storage. (disk). And that matters, if you need to look at such
things.. (in a disk editor, for example)..

Chris has a life. He also posts in many other forums, both on MSNews and
elsewhere. He only drops in here from time to time.

--
Gary S. Terhune
MS MVP Shell/User

"Dan" wrote in message
...
PCR or anyone else --- Where is cquirke? I definately miss his unique
way of
analyzing situations. Please don't inform me that he has jumped ship
to
another newsgroup. If he has I understand but will be saddened
because it
will be a great loss since Chris has been a great asset to this group,
imo.

"PCR" wrote in message
...
: "Kentiguous" wrote in message
: ...
: | PCR wrote :
: | "Kentiguous" wrote in message
: | ...
: | | PCR wrote :
: | ...those were my settings. NOW, I have made the second to be
"Prompt"
: | as
: | well. In fact, as a punishment to me, I have changed every single
one
: | of
: | them in that section to "Prompt", where formerly it was only the
last
: | one...
: |
: | LostClust = Prompt ; Lost clusters
: |
: | Boot_Sector = Prompt ; Damaged boot sector on DoubleSpace
drive
: | FSInfo_Sector = Prompt ; Incorrect free space count
: | Invalid_MDFAT = Prompt ; Invalid MDFAT entries
: | DS_Crosslinks = Prompt ; Internal (MDFAT-level) crosslinks
: | DS_LostClust = Prompt ; Internal lost clusters
: | DS_Signatures = Prompt ; Missing DoubleSpace volume signatures
: | Mismatch_FAT = Prompt ; Mismatched FATs on non-DoubleSpace
drives
: | Bad_Clusters = Prompt ; Physical damage or decompression
errors
: |
: | There are other settings ("Bad_Entries", "Okay_Entries",
"Bad_Chain",
: | "Crosslinks", "LabelCheck", "LfnCheck", "SpaceCheck", etc.) that
you
: | may want to alter, too. I'd suggest going through SCANDISK.INI
: | 'with a fine-tooth comb', in order to obtain the behaviour that
you
: | desire.
:
: My fine-tooth comb is full of gook. However, except for the HDD
crash of
: 2001 which is less/less vivid to me, nothing horrible has turned up
in
: Scandisk.log. So, I've still got time. Do not tell cquirke I haven't
: gotten to it, yet, though! I DID get to it, (but quit before I was
: done).
:
: WELL... let me see what yours looks like.
:
: |
: | | There are no references to Scandisk in either IO.SYS or
: COMMAND.COM,
: | | in Win98SE. WIN.COM is a DOS executable file.
: |
: | That's odd. Did you see my quote of Badour...?...
: |
: | ...elsewhere in this thread.
: |
: | I did; then I fired-up my hex editor to re-check the results that
I
: | posted, above. I guess Ron's info. was Win95 OSR 2.x specific;
: | but, I have no easy way of verifying that.
:
: That is still odd. Let me read the article again...
:
: ......Quote................
: OSR2 includes versions of the Io.sys and Win.com files that check
the
: Clean Shutdown and Hard Disk Error bits in the Virtual File
Allocation
: Table (VFAT) during startup. If either of these bits is turned on
(that
: is, cleared to 0) on any drive present in real mode, you are
prompted to
: run ScanDisk
: ......EOQ...................
:
: IO.sys is DOS. WIN.com is Windows. OSR2 is... ???. However, we do
know
: the mechanism that Auto-runs Scandisk still does exist.
:
: |
: | | | | scandisk /ALL /NOSUMMARY
: | | | | if not errorlevel 1 goto scend2
: | | | | echo Errors found! Press a key to re-scan/fix local
: drive(s)...
: | | | | pausenul
: | | | | scandisk /ALL
: | | | | :scend2
: | | |
: | | | I don't like the looks of that. The second run will not
find
: any
: | | | errors.
: | | |
: | | | Yes, it will (see below).
: | |
: | | OK.
: | |
: | | |
: | | | The first run did not record it's summary. (It may be the
: summary
: |
: | | | & the
: | | | error report are two different things, though, not sure.)
: | | |
: | | | They are two different things; but even if they weren't, the
: | | | non-creation (or deletion) of SCANDISK.LOG will not affect
: | | | Scandisk's
: | | | ability to detect subsequent errors.
: | |
: | | OK, they're different. STILL, the second run will not find the
: | | errors
: | | that were fixed in the first run. Therefore, it is important
to
: | | select
: | | "append" for the .log, not "overwrite", if you are going to
run it
: | | twice
: | | in a row!
: | |
: | | The first run will not fix the errors, here (hence, the need
for
: the
: | | second run). If the first run did fix the errors, it would be
: rather
: | | difficult for Scandisk to fix them, during the second run, if
they
: no
: | | longer existed. g Logging is irrelevant WRT Scandisk's
ability to
: | | fix
: | | errors. You can use "SaveLog=Off", in SCANDISK.INI to disable
: | | logging.
: |
: | I thought/think it is "/CHECKONLY" that does that, not
"/NOSUMMARY".
: |
: | Try it. One can't argue with 'real-world' results.
:
: C:\scandisk/?
: For information about the command-line parameters supported by
: ScanDisk for Windows, look up 'checking for errors, in disks' in
: the Windows Help index. Then view the topic 'Checking your disk
: for errors every time your computer starts.'
:
: ...There is no real info about it where DOS instructs one to look.
Be
: more descriptive of your "real-world results". You used
"/NOSUMMARY", &
: I'm sure you got no summary. What makes you sure it did no fix,
which I
: think /CHECKONLY would be for? What, if anything, was in
Scandisk.log
: after a /NOSUMMARY run?
:
: |
: | Ken
: |
: | --
: | Remove the '4' to reply via email
:
: --
: Thanks or Good Luck,
: There may be humor in this post, and,
: Naturally, you will not sue,
: should things get worse after this,
: PCR
:
:
:

I see Terhune offers an answer. I suppose it could be some denizens of
this NG could have a "life" (whatever that is), just as Terhune
speculates. I cannot verify whether the truth is that, or whether
cquirke fell into an XP-pit. Here is his site...
http://cquirke.mvps.org/9x/
....It doesn't appear at first glance to be aglow in radiation.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Dan" wrote in message
...
| PCR or anyone else --- Where is cquirke? I definately miss his unique
way of
| analyzing situations. Please don't inform me that he has jumped ship
to
| another newsgroup. If he has I understand but will be saddened
because it
| will be a great loss since Chris has been a great asset to this group,
imo.
|
| "PCR" wrote in message
| ...
....snip

"Bill Blanton" wrote in message
...
|
| "PCR" wrote in message
...
| "Bill Blanton" wrote in message
| ...
| |
| | "PCR" wrote in message
| ...
| | "Bill Blanton" wrote in message
| | ...
| | |
| | | "PCR" wrote in message
| | ...
| |
| |
| | | | "high two bits", not "two low order bits". FAT32 only uses
28
| bits
| | | | for cluster entries so it will be bit-26 and bit-27 of the
| dword FAT[1}
| | | | entry.
|
| Yikes. I missed this last read (or last couple of them). Then, the
| Badour article begins to look good...
|
| "the two low-order bits of the FAT entry for cluster 1".
|
| Bit's 26 & 27, counting from zero, turn out to be that.
|
| The low order bit (LSBit) is always bit-0. ("on the right" (x), if
| written in "readable form") 111111x. The high order bit (MSBit) is
| of course width-1. Bit-7 in an 8 bit byte.

Right. But what are those articles referring to? Are they referring to
the "subthing"? If to the "subthing", are they referring to it in a
register (makes most sense) or to it as stored in the FAT?

The Badour artiicle said...

"the two low-order bits of the FAT entry for cluster 1".
....That might be the "subthing".

Your MS FAT spec lit said...

"the file system driver may use the high two bits of the FAT[1] entry".
....I guess that might be the "subthing" too, as you say these are 28
bits.

But is one of them speaking of it as stored & the other in a register?

Register: 01111111 11111111 11111111 11111111
Stored: 11111111 11111111 11111111 01111111
Subthing: ???.

....snip
| |
| | "High-order" is high order either way. :-\
|
| High-order is the leftmost bits. If they are stored left-to-right,
then
| they are no longer the high-order bits, until they are read back
into a
| register.
|
| No matter how you mix up the bits the high-order bit is always the
MSBit.
| That's why I said refering to "Left" and "Right" acn confuse the
issue.
| Unless you're looking at the "whole", as we humans like to look at
numbers.
| (maybe that's why they came up with the terms "high and low" in the
| first place?. "Left and "right" don't really cut it)

LEFTER = MORE SIGNIFICANT = HIGHER ORDER = GREATER VALUE. That's all!
Well, if nibbles are stored backwards, then one must know what one is
speaking of-- the stored thing or the thing as retrieved into a
register.

|
|
| Again, after the intel processor pokes a dword in memory, such as
| | | dword 11111111 11111111 11111111 01111111 the high order
| ..bit is where the zero is. The high order -byte- (or MSB) of the
| dword would be 01111111.
|
|
|
| |
| | The bit you have turned off there is the high-order (leftmost)
bit
| of
| | the pre-storage/post-retrieval DWORD.
| |
| | "In storage". In a CPU register the high-order bit of a dword
would
| | be here- 01111111111111111111111111111111 Those four bytes moved
to
| | memory will be as above paragraph.
|
| That is what I mean by the pre-storage/post-retrieval value, which
| normally one would presume to be all that is spoke of. Once this is
| stored, that off bit (0) will no longer be the highest-order bit.
|
| The "high order bit" is always the high order bit :-| and doesn't
change
| if you store it backwards. It "looks" like it's in a different
position
| if you do a memory dump to screen, or look at a larger than byte value
| in other storage. (disk). And that matters, if you need to look at
such
| things.. (in a disk editor, for example)..

If you look at the stored field, it's highest-order bit is the leftmost.
If you look at what is inside a register, it's highest-order bit is the
leftmost. Apparently these won't be the same bits, because of the manner
in which nibbles are switched during storage/retrieval, not to mention
the creation of a "subthing".

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

I understand and that makes perfect sense. Thanks Gary for clearing my head
in this matter. Although, I really enjoy reading Chris's responses to posts
that involve MS-DOS.

"Gary S. Terhune" wrote in message
...
: Chris has a life. He also posts in many other forums, both on MSNews and
: elsewhere. He only drops in here from time to time.
:
: --
: Gary S. Terhune
: MS MVP Shell/User
:
: "Dan" wrote in message
: ...
: PCR or anyone else --- Where is cquirke? I definately miss his unique
: way of
: analyzing situations. Please don't inform me that he has jumped ship
: to
: another newsgroup. If he has I understand but will be saddened
: because it
: will be a great loss since Chris has been a great asset to this group,
: imo.
:
: "PCR" wrote in message
: ...
: : "Kentiguous" wrote in message
: : ...
: : | PCR wrote :
: : | "Kentiguous" wrote in message
: : | ...
: : | | PCR wrote :
: : | ...those were my settings. NOW, I have made the second to be
: "Prompt"
: : | as
: : | well. In fact, as a punishment to me, I have changed every single
: one
: : | of
: : | them in that section to "Prompt", where formerly it was only the
: last
: : | one...
: : |
: : | LostClust = Prompt ; Lost clusters
: : |
: : | Boot_Sector = Prompt ; Damaged boot sector on DoubleSpace
: drive
: : | FSInfo_Sector = Prompt ; Incorrect free space count
: : | Invalid_MDFAT = Prompt ; Invalid MDFAT entries
: : | DS_Crosslinks = Prompt ; Internal (MDFAT-level) crosslinks
: : | DS_LostClust = Prompt ; Internal lost clusters
: : | DS_Signatures = Prompt ; Missing DoubleSpace volume signatures
: : | Mismatch_FAT = Prompt ; Mismatched FATs on non-DoubleSpace
: drives
: : | Bad_Clusters = Prompt ; Physical damage or decompression
: errors
: : |
: : | There are other settings ("Bad_Entries", "Okay_Entries",
: "Bad_Chain",
: : | "Crosslinks", "LabelCheck", "LfnCheck", "SpaceCheck", etc.) that
: you
: : | may want to alter, too. I'd suggest going through SCANDISK.INI
: : | 'with a fine-tooth comb', in order to obtain the behaviour that
: you
: : | desire.
: :
: : My fine-tooth comb is full of gook. However, except for the HDD
: crash of
: : 2001 which is less/less vivid to me, nothing horrible has turned up
: in
: : Scandisk.log. So, I've still got time. Do not tell cquirke I haven't
: : gotten to it, yet, though! I DID get to it, (but quit before I was
: : done).
: :
: : WELL... let me see what yours looks like.
: :
: : |
: : | | There are no references to Scandisk in either IO.SYS or
: : COMMAND.COM,
: : | | in Win98SE. WIN.COM is a DOS executable file.
: : |
: : | That's odd. Did you see my quote of Badour...?...
: : |
: : | ...elsewhere in this thread.
: : |
: : | I did; then I fired-up my hex editor to re-check the results that
: I
: : | posted, above. I guess Ron's info. was Win95 OSR 2.x specific;
: : | but, I have no easy way of verifying that.
: :
: : That is still odd. Let me read the article again...
: :
: : ......Quote................
: : OSR2 includes versions of the Io.sys and Win.com files that check
: the
: : Clean Shutdown and Hard Disk Error bits in the Virtual File
: Allocation
: : Table (VFAT) during startup. If either of these bits is turned on
: (that
: : is, cleared to 0) on any drive present in real mode, you are
: prompted to
: : run ScanDisk
: : ......EOQ...................
: :
: : IO.sys is DOS. WIN.com is Windows. OSR2 is... ???. However, we do
: know
: : the mechanism that Auto-runs Scandisk still does exist.
: :
: : |
: : | | | | scandisk /ALL /NOSUMMARY
: : | | | | if not errorlevel 1 goto scend2
: : | | | | echo Errors found! Press a key to re-scan/fix local
: : drive(s)...
: : | | | | pausenul
: : | | | | scandisk /ALL
: : | | | | :scend2
: : | | |
: : | | | I don't like the looks of that. The second run will not
: find
: : any
: : | | | errors.
: : | | |
: : | | | Yes, it will (see below).
: : | |
: : | | OK.
: : | |
: : | | |
: : | | | The first run did not record it's summary. (It may be the
: : summary
: : |
: : | | | & the
: : | | | error report are two different things, though, not sure.)
: : | | |
: : | | | They are two different things; but even if they weren't, the
: : | | | non-creation (or deletion) of SCANDISK.LOG will not affect
: : | | | Scandisk's
: : | | | ability to detect subsequent errors.
: : | |
: : | | OK, they're different. STILL, the second run will not find the
: : | | errors
: : | | that were fixed in the first run. Therefore, it is important
: to
: : | | select
: : | | "append" for the .log, not "overwrite", if you are going to
: run it
: : | | twice
: : | | in a row!
: : | |
: : | | The first run will not fix the errors, here (hence, the need
: for
: : the
: : | | second run). If the first run did fix the errors, it would be
: : rather
: : | | difficult for Scandisk to fix them, during the second run, if
: they
: : no
: : | | longer existed. g Logging is irrelevant WRT Scandisk's
: ability to
: : | | fix
: : | | errors. You can use "SaveLog=Off", in SCANDISK.INI to disable
: : | | logging.
: : |
: : | I thought/think it is "/CHECKONLY" that does that, not
: "/NOSUMMARY".
: : |
: : | Try it. One can't argue with 'real-world' results.
: :
: : C:\scandisk/?
: : For information about the command-line parameters supported by
: : ScanDisk for Windows, look up 'checking for errors, in disks' in
: : the Windows Help index. Then view the topic 'Checking your disk
: : for errors every time your computer starts.'
: :
: : ...There is no real info about it where DOS instructs one to look.
: Be
: : more descriptive of your "real-world results". You used
: "/NOSUMMARY", &
: : I'm sure you got no summary. What makes you sure it did no fix,
: which I
: : think /CHECKONLY would be for? What, if anything, was in
: Scandisk.log
: : after a /NOSUMMARY run?
: :
: : |
: : | Ken
: : |
: : | --
: : | Remove the '4' to reply via email
: :
: : --
: : Thanks or Good Luck,
: : There may be humor in this post, and,
: : Naturally, you will not sue,
: : should things get worse after this,
: : PCR
: :
: :
: :
:
:
: