Cluster size and exploring the limits of FAT-32
98 Guy
limits of increasing the cluster count on FAT-32 drives under
win-98se.
My experience so far is that both DOS and Win98-se seem to work fine
when installed on and accessing volumes formatted with a substantially
higher number of clusters than format.com would normally create.
Specifically, a 160 gb SATA drive formatted with 4 kb cluster size
resulting in about 40 million clusters (about 20 times the number of
clusters that format would normally use, and about 10 times the number
that is often quoted as the maximum allowable under conventional
FAT-32 rules).
While win-98 does indeed function "normally", it's two main drive
maintainence tools (scandisk and defrag) do not work. For example,
defrag (windows version) will give this error when attempted on a 32
gb SATA volume with 7.8 million clusters:
"Your computer does not have enough free memory to defragment
this drive. Quit one or more programs and then try
defragmenting this drive again". ID No. DEFRAG009"
This even when the computer has 512 mb of installed memory.
With regard to alternate tools (such as Norton Utilities), when
running Norton Disk Doctor or Speed Disk (from the System Works 2002
suite), both will display this message:
"Drive x may not be configured correctly. Norton Speed Disk
can not run on this drive."
According to this:
http://discussions.virtualdr.com/showthread.php?t=103297
"To prevent the message and allow Norton Disk Doctor and
Speed Disk to complete, run NDD.EXE and NDD32.EXE with
the /NOLBA switch."
This worked with the 32 gb drive with 4kb cluster size (7.8 million
clusters) for both NDD and SD, but I got a blue-screen "fatal
exception OE" error when I tried to run both NDD and SD on the larger
partition (121 gb with 4k cluster size - 31.2 million clusters).
The fatal exception error did not list a module or process that caused
the error - only a memory location.
Sort of like this:
http://www.windowstruthzone.com/mission/crash.html
Norton system information correctly reported the information for both
logical drives (7.8 million and 31.2 million clusters respectively).
To force Norton Disk Doctor and Speed Disk to always skip the drive
configuration check, add a DWORD registry value named NOLBACHECK at
this location:
HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities
When this option is set to 1, Norton Disk Doctor and Speed Disk skip
the drive configuration check.
Norton Image seems to run ok on the 32 gb partition (even without the
/NOLBA switch) but again a "Fatal exception 0E" results when attempted
on the 121 gb partition.
Some tests with backing up these drives with Norton Ghost 2003 show
that while Ghost will clone the 32 gb partition, it will not maintain
the original 4kb cluster size and will revert to a 16 kb cluster size
on the destination drive. Ghost will fail and seems unable to clone
the larger partition at all (31 million clusters).
So, to conclude:
1) Technically DOS and Windows 98se can operate from and access FAT-32
volumes that have been formatted using a cluster count much larger
than has been previously reported as the upper limit for FAT-32. Such
drives must be prepared by third-party drive tools such as OnTrack
Disc Manager or it's drive-specific equivalents (such as Seagate's
Disc Wizard). Volumes with up to 40 million clusters have been
created and have been found to be compatible with Win-98.
2) In spite of (1) above, two key drive tools (Defrag and Scandisk)
are NOT compatible with volumes of 7.8 million (or more) clusters.
Further testing is necessary to confirm that the native win-98 defrag
and scandisk are indeed hard-limited to the often-quoted 4 million
cluster count.
3) Assuming that the Norton Utilities eqivalent to Defrag and Scandisk
are competent replacements for the native windows tools, then the
Norton programs are compatible with volumes with up to 8 million
clusters, but not 31.2 million. Further testing is necessary to
determine the cluster-count limitation for NDD and SD.
Vic
Being I still use Win98 a LOT and have multiple drives much larger than
8gb, one drive with tens of thousands of small files in 32k clusters, I
know much drive space could be saved by moving to 4k clusters. Hope you
will continue to keep us updated on your research. It would be
especially to know if scandskw and defrag COULD be used ultimately.
___
"98 Guy" <9...@Guy.com> wrote in message news:45DD3234...@Guy.com...
Haggis
"Vic" <nos...@bogusaddress.com> wrote in message
news:OyJQl9q...@TK2MSFTNGP02.phx.gbl...
nice info ...have you tried diskeeper to see if it would handle the defrag
?
98 Guy
says) is a bootable CD which allows you to select and run a number of
different utility, diagnostic, and repair applications. Major
catagories are:
- Disk Partition tools
- Disk Clone tools
- Antivirus tools
- Recovery tools
- Testing tools
- Hard disk tools
- System info tools
- File managers
- MBR tools
- BIOS/CMOS tools
- Multimedia tools
- Password and registry tools
- FileSystem tools (NTFS, ext2FS, ext3FS)
Under Partition tools we have:
- Partition Magic Pro 8.05
- Acronis Disk Director Suite 9.0.554
- Paragon Partition Manager Server 7.0.1274
- Partition Commander 9.01
And others. Under Clone tools we have Norton Ghost 8.3, ImageCenter
5.6 (drive image), Acronis True image, etc.
So basically lots of toys to play with.
As already reported, I've created a 32 gb volume with 4 kb cluster
size with win-98 installed. The volume has close to 8 million
clusters, and as mentioned before I've found out what works, and what
doesn't work with a volume configured that way. I've also found that
Ghost can copy that volume to another drive, but will change the
cluster size to 16kb on the destination drive.
While fooling around with PartitionMagic Pro Server 8.05 (which is a
Norton product?) I thought I might try to re-size the cluster size on
the clone. That's when I found that yes, PM will let me change the 16
kb clusters to 4kb clusters, but in doing so it also changes the size
of the volume. The two are linked, and I can't "de-link" them.
Ok, so what does it change the size of the volume to? About 25 gb.
Interesting. I go ahead with the change, and then boot the drive back
into win-98.
Windows tools like defrag and scandisk still are not able to deal with
the new (smaller) cluster count, but Norton Disk Doctor and Norton
Speed Disk can - without using the previously mentioned /NOLBA
switch. Also noteworthy is that DOS scandisk *does* function
correctly (!).
So now here's the important stuff. According to chkdsk the geometry
of the volume is this:
25,164,815 kilobytes total disk space
4096 bytes in each allocation unit
6,291,204 total allocation units on disk
Now why did PM scale back the cluster count to about 6.3 million? Why
is that a *magic number* ?
This link talks about why the max number of clusters is supposed to be
4,177,920:
But that doesn't explain why I'm seeing DOS scandisk being compatible
with 6.3 million clusters.
One other thing. When booting directly into DOS with these various
drives there is a delay when the first "dir" command is performed. It
takes a noticable amount of time to perform the DIR the first time,
and in particular to display the amount of free space. Given a 160 gb
volume with 40 million clusters, it took a full 5 minutes to get the
free space result. On the 32 gb volume with 7.8 million clusters, it
took about a minute.
However, given the new configuration (6.3 million clusters) the dir
command executes instantly, with no delay in computing the free space.
So I think this makes a good case that you can safely create and
operate a 25 gb volume with win-98 using 4kb cluster size, especially
if you have something like Norton Disk Docter and Speed Disk.
98 Guy
I previously reported that DOS scandisk runs fine on a volume with 6.3
million clusters, which exceeds the stated (by MS) upper limit of
4,177,920.
So here's what new:
Take a 160 gb sata drive, boot from win-98 floppy (with updated
fdisk), use fdisk to create a single primary partition using the
entire drive. Then run format (no command line switches).
About an hour later, the result is:
Output of format:
-----------------
152,588.03 MB total disk space
360,448 bytes used by system
152,587.69 MB available on disk
32,768 bytes in each allocation unit
4,882,805 allocation units available on disk
-----------------
Output of chkdsk:
----------------
156,250,144 kilobytes total disk space
156,249,760 kilobytes free
32,768 bytes in each allocation unit
4,882,817 total allocation units on disk
4,882,805 available allocation units on disk
---------------
Note that the result is a volume which exceeds the 4.177 million
cluster limit. Which means (according to MS) that DOS scandisk should
not be compatible with this volume.
However, Scandisk.exe ran fine. It took about 15 seconds to check the
drive (without performing a surface test).
A dir command is also performed instantly with no delays in computing
free space.
If 6.3 million clusters is the limit for DOS scandisk, then given 32kb
cluster size that would put the largest volume that win-98 could
theoretically handle (assuming you are willing to give up windows
scandisk and defrag but still have DOS scandisk compatibility) at
about 206 gb.
Perhaps that's the reason for the existance of a 200 gb drive size?
cquirke (MVP Windows shell/user)
>I'm using something called "Hiren's Boot CD v 8.7" which (as the name
>says) is a bootable CD which allows you to select and run a number of
>different utility, diagnostic, and repair applications.
Oh, I remember the Hiren CD!
>As already reported, I've created a 32 gb volume with 4 kb cluster
>size with win-98 installed. The volume has close to 8 million
>clusters, and as mentioned before I've found out what works, and what
>doesn't work with a volume configured that way. I've also found that
>Ghost can copy that volume to another drive, but will change the
>cluster size to 16kb on the destination drive.
OK. It's interesting how BING just shrugs and changes cluster size
while resizing across boundaries; no problems. Nice, in a way, but
not if you wanted to keep the non-default.
>While fooling around with PartitionMagic Pro Server 8.05 (which is a
>Norton product?)
I dunno when it became notionally a Norton product, i.e. when
post-Norton Symantec bought them out.
>That's when I found that yes, PM will let me change the 16
>kb clusters to 4kb clusters, but in doing so it also changes the size
>of the volume. The two are linked, and I can't "de-link" them.
>Ok, so what does it change the size of the volume to? About 25 gb.
>Interesting. I go ahead with the change, and then boot the drive back
>into win-98.
>Windows tools like defrag and scandisk still are not able to deal with
>the new (smaller) cluster count, but Norton Disk Doctor and Norton
>Speed Disk can - without using the previously mentioned /NOLBA
>switch. Also noteworthy is that DOS scandisk *does* function
>correctly (!).
Nice! I always preferred DOS mode Scandisk to the Windows one,
especially as it shows up latency on surface scanning really well.
>So now here's the important stuff. According to chkdsk the geometry
>of the volume is this:
>
>25,164,815 kilobytes total disk space
>4096 bytes in each allocation unit
>6,291,204 total allocation units on disk
>
>Now why did PM scale back the cluster count to about 6.3 million? Why
>is that a *magic number* ?
6 300 000 x 4 bytes / 1024 / 1024 = 24M, which seems familiar... is it
the biggest chunk of RAM a RAM drive can use, or something?
>This link talks about why the max number of clusters is supposed to be
>4,177,920:
>But that doesn't explain why I'm seeing DOS scandisk being compatible
>with 6.3 million clusters.
The whole article smells whiffy...
"You cannot format a volume larger than 32 GB in size using the FAT32
file system in Windows 2000. The Windows 2000 FastFAT driver can mount
and support volumes larger than 32 GB that use the FAT32 file system
(subject to the other limits), but you cannot create one using the
Format tool. This behavior is by design."
With me so far? An arbitrary limit "by design" to force you to use
NTFS instead - for which good maintenance/recovery tools don't exist.
"NOTE: When attempting to format a FAT32 partition larger than 32 GB,
the format fails near the end of the process with the following error:
Logical Disk Manager: Volume size too big."
So the best "design" they can come up with is to trash the space being
formatted, take agest to reach the 32G mark, and then fall on it's
ass? How about testing the size before you START formatting?
Sheesh. I hate it when vendors try to make Shiny New B look better
than Good Old A by crippling A.
>One other thing. When booting directly into DOS with these various
>drives there is a delay when the first "dir" command is performed. It
>takes a noticable amount of time to perform the DIR the first time,
>and in particular to display the amount of free space. Given a 160 gb
>volume with 40 million clusters, it took a full 5 minutes to get the
>free space result. On the 32 gb volume with 7.8 million clusters, it
>took about a minute.
Clearly there's some rollover effect going on... wait a moment, 160G
is over the 137G limit, so all bets are off in Win9x!
Originally, free space was as simple as counting how many FAT entries
were 0. That's quick enough when holding a 16-bit FAT in memory, but
becomes onerous with larger 32-bit FATs - so a value of the free space
is held in the FAT32 boot record (which is now 3 sectors long).
Chances are the OS doesn't "trust" this value on first boot, as some
other OS may have operated on the file system without updating it, or
something. If so, then the first Dir will recalculate it afresh.
>However, given the new configuration (6.3 million clusters) the dir
>command executes instantly, with no delay in computing the free space.
I dunno if it's a > 137G thing or a cluster count thing.
>So I think this makes a good case that you can safely create and
>operate a 25 gb volume with win-98 using 4kb cluster size, especially
>if you have something like Norton Disk Docter and Speed Disk.
Does it matter where in the > 137G space the volume starts?
>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
>--------------- ---- --- -- - - - -
98 Guy
http://www.mvps.org/serenitymacros/winprogs.html
------------
Scandisk only uses the first FAT to repair disks and copies it over
the second after it repairs it. Scandskw uses both
FATS to make repairs, using the best information from each. Scandskw
is only a starter application. Dskmaint.dll does
all the work.
------------
So on a hunch, I went to look for other versions of dskmaint.dll, and
I found one here:
http://rapidshare.com/files/16328925/Big_HDD_2.0.zip.html
It's the Windows ME versions of diskmaint.dll, defrag.exe, and some
other stuff.
After replacing the existing win-98se version with this new one,
windows scandisk (scandskw.exe) was able to run
properly and scan the volumes I had previously created (the ones with
6.3 million and 4.9 million clusters).
Interesting that Norton (both NDD and SD without using the /NOLBA
switch) are not compatible with the 160 gb volume formatted by the DOS
tools (32kb cluster size, 4.9 million clusters) but they were
compatible with the 25 gb volume (4kb cluster size, 6.3 million
clusters).
The Win-ME version of defrag.exe also worked on both volumes. It
would appear that the ME version of defrag is
somehow tied to, or part of, the Intel Application Accelerator (?)
Now that I'm running win-98 with the Win-ME versions of dskmaint.dll
and defrag.exe, I tried them on another drive with
2 volumes (32 gb / 4kb cluster size / 7.8 million clusters and 121 gb
/ 4kb cluster size / 31.2 million clusters) and
guess what - no problems.
So at this point one thing that I haven't looked into yet is the
Win-ME version of scandisk.exe. I've poked around the net but haven't
seen one available for download, so I'll have to crack open my MSDN
binders and grab it from there.
Summary:
1) Windows ME versions of dskmaint.dll and defrag.exe gives Windws-98
a great deal more compatibility with large hard drives and large
volumes formatted with small cluster size that results in a more
efficient use of drive space (and presumably better performance).
Compatibility with volume size of up to 31.2 million clusters has been
observed.
98 Guy
> > One other thing. When booting directly into DOS with these
> > various drives there is a delay when the first "dir" command
> > is performed. It takes a noticable amount of time to perform
> > the DIR the first time, and in particular to display the amount
> > of free space. Given a 160 gb volume with 40 million clusters,
> > it took a full 5 minutes to get the free space result. On the
> > 32 gb volume with 7.8 million clusters, it took about a minute.
>
> Clearly there's some rollover effect going on... wait a moment,
> 160G is over the 137G limit, so all bets are off in Win9x!
Um, well, sort of.
First, remember that older motherboards had a 137 gb limitation built
into their bios. Assuming that we're dealing with a moderm
motherboard without that problem, then yes, the original (and as far
as I know the only) version of ESDI_506.PDR for win-98se is also
limited to 137 gb. ESDI_506.PDR is what windows uses for 32-bit drive
access. Without it, windows resorts to 16-bit "compatibility mode"
drive access, which is (I think) the same type of access that DOS
uses.
So yes, DOS by itself is compatible with drives larger than 137 gb.
> > However, given the new configuration (6.3 million clusters) the
> > dir command executes instantly, with no delay in computing the
> > free space.
>
> I dunno if it's a > 137G thing or a cluster count thing.
I think it's cluster count.
But there's still this: Ever run NDD and have it tell you that the
free space is being reported incorrectly, and that it can fix it for
you?
I wonder if there's an entry in the FAT or MBR or somewhere that holds
the free remaining space so that it doesn't have to be computed all
the time, and NDD can read that and see if it agrees with the actual
clusters in use.
> > So I think this makes a good case that you can safely create
> > and operate a 25 gb volume with win-98 using 4kb cluster size,
> > especially if you have something like Norton Disk Docter and
> > Speed Disk.
>
> Does it matter where in the > 137G space the volume starts?
I think the answer depends on if we're talking about an IDE drive or a
SATA drive. Or perhaps more correctly if we're talking about a drive
being managed by a RAID controller or being mapped to (or actually
connected to) an IDE controller.
Given a large (>137 gb) ordinary IDE hard drive connected to the
standard primary or secondary IDE controller, then yes, everything
I've read indicates that because ESDI_506.PDR uses 32-bit addressing,
it will corrupt the drive when it attempts to (write?) beyond the 137
gb boundary. There is a modified version of ESDI_506.PDR that has
been "fixed" and uses the correct 48-bit addressing.
The same situation happens (I think) when a SATA drive is used in a
non-raid mode, in which case it's mapped to appear as if it's
connected to a conventional IDE controller, in which case windows will
use ESDI_506.PDR to access it.
On the other hand, a large drive (IDE or SATA) that's connected to a
RAID controller (and not necessarily used as part of a RAID set) will
use a vendor-specific windows driver that (presumably) is using 48-bit
addressing, in which case there will be no 137 gb problem. That's
what I've been doing. I've had 1 or 2 SATA drives connected to the
system but have told the BIOS to use the RAID controller to manage
them. In the RAID setup I haven't defined them (one or both) as being
part of a RAID set.
Bill in Co.
I take it "Recovery Console" doesn't quite qualify?
(As I've said before, I've never used NTFS, so all I get is this information
by the wayside. I'm still using FAT32 (and DOS, of course), as the
fallback, and that's all I know).
98 Guy
discovery, which is that DOS scandisk (both the original win-98
version and the windows ME version) don't really seem to have a
cluster size limitation.
Specifically, here's what I've just tested:
drive c: 25 gb / 4kb cluster size / 6.3 million clusters
drive d: 31 gb / 4kb cluster size / 7.8 million clusters
drive e: 125 gb / 4kb cluster size / 31.2 million clusters
drive f: 156 gb / 32kb cluster size / 4.9 million clusters
drive (c) is SATA drive 1
drive (d) and (e) are SATA drive 2
drive (f) is SATA drive 3
Drive C has win-98se installed, and instead of starting 98 I instead
brought up the start menu and started in DOS. From the command
prompt, I ran scandisk (Win-98se and Win-ME).
Both of them ran fine on all of the above volumes.
Previously when I was testing dos scandisk.exe, I was booting from a
floppy, and probably wasn't loading himem.sys. Himem.sys is needed by
scandisk to run properly.
So here is the master summary of this thread:
---------------------------
1) Scandisk (DOS scandisk.exe, not Windows scandskw.exe) does not
appear to have a cluster-count limitation. Both Win-98se and Win-ME
versions of scandisk have been run on drives with up to 31 million
clusters and have executed properly with no errors. Himem.sys must be
loaded for scandisk to function properly. Microsoft states that
FAT-32 volumes are limited to 4.17 million clusters because of
scandisk.exe, and that scandisk.exe is limited to a memory or data
array size of 16 million bytes. It could very well be that this 16 mb
limit is based on Microsoft's stated minimum system requirements for
Windows 98 (which is 16 mb of system RAM) and that scandisk will
automatically make use of all available system memory if required.
----------------------------
2) Win-98se has been installed directly on 160 gb volumes formatted
with 4kb cluster size (resulting in 40 million clusters) and has not
shown any instability. This was performed on a 160 gb SATA drive
assigned to a RAID controller (but not used in RAID mode). To test
for 137gb data corruption (which theoretically takes place when a read
or write across the 137 gb boundary occurrs) a series of 1 gb VOB
files were copied repeatedly in order to fill the drive. The drive
was eventually filled with 150 of these 1 gb files, and no drive
corruption occurred.
----------------------------
3) The only drawback that I've seen when running a volume with a large
cluster count is that DOS will take a much longer time to perform the
first DIR command. This might also happen in Windows as well - I may
have seen this effect but I haven't specifically looked for it. The
issue is the computation and display of free remaining drive space,
which is part of the DIR command and also happens when browsing the
drives in windows. Related to this is the question does windows store
the amount of remaining drive space somewhere on the drive (instead of
requiring it to be re-calculated every time it's needed).
---------------------------
4) Standard DOS tools like fdisk and format can be used to partition
and format hard drives in excess of 137 gb. Fdisk was used to
partition a 160 gb drive into a 32 gb primary and 121 gb secondary.
The updated or "fixed" version of fdisk.exe was used. What has not
been tested (yet) is the undocumented /Z:n command line parameter for
format, which allows the user to specify a particular cluster size (n
x 512 bytes). Third-party drive utilities (based on On Track's Disc
Manager) can also be used to partition and format hard drives, but I
have found those utilities to be very unstable and to lock up/crash
about 75% of the time I use them.
---------------------------
5) There is evidence that 6,291,204 clusters may represent some sort
of "magic number". A third-party drive partition tool (PartitionMagic
Pro Server 8.05) resorted to this cluster count when an existing 32 gb
partition was manually resized to 4kb cluster size. Norton Disk
Doctor and Speed Disk was found to work properly using this cluster
count, but not on a volume with a slightly larger cluster count of 7.8
million clusters (see note 7 below). This 6.3 million cluster count,
combined with 32kb cluster size, results in a volume size of 206 gb.
Perhaps this set of parameters is the reason for the 200 gb hard drive
size which emerged in early to mid 2003. A dir command is also
performed instantly with no delays in computing free space given a
volume with 6.3 million clusters.
---------------------------
6) Win-98 versions of Scandisk (scandskw.exe) and Defrag did not
function on a volume with 6.3 million clusters but seems to be limited
to the MS stated value of 4.17 clusters. However, Windows ME versions
of dskmaint.dll and defrag.exe does appear to function correctly with
Windows 98se and compatibility with volume size of up to 31.2 million
clusters has been observed. It is not know what their ultimate limit
is.
----------------------------
7) Norton Utilities is a very common third-party set of applications
and their compatibility with large hard drives with a large cluster
count may be of importance to some people. I have found that Norton
Disk Doctor and Norton Speed disk were compatible with volumes with up
to 6.3 million clusters, but not more without using the command-line
parameter /NOLBA. When using this parameter, NDD and SD worked on
volumes with 7.8 million clusters but not 31 million. The exact
cluster-count limit is therefore unknown at this point and I may
explore that in the future.
The switch /NOLBA forces NDD and SD to skip the drive configuration
check. This can also be done using a registry entry by adding a DWORD
registry value named NOLBACHECK at this location:
HKEY_LOCAL_MACHINE\Software\Symantec\Norton Utilities
When this option is set to 1, Norton Disk Doctor and Speed Disk skip
the drive configuration check.
----------------------------
8) Anyone considering adding a large hard drive (a drive larger than
137 gb) to an existing win-98 computer needs to consider certain
issues that include the drive type (IDE/PATA vs SATA) as well as how
the drive is controlled by the motherboard BIOS (mapped to IDE channel
or controlled by RAID controller). The main issue here is that you DO
NOT WANT the win-98se 32-bit driver (ESDI_506.PDR) to be used to
access a hard drive larger than 137 gb. Many or most motherboards
made for the past 3 years will have built-in SATA ports. Windows-98
users are advised to obtain SATA drives instead of the older
conventional IDE drives when adding a new drive (larger than 137 gb)
to a system or if building a new system.
cquirke (MVP Windows shell/user)
>http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:
>80/support/kb/articles/
>> The whole article smells whiffy...
>>
>> "You cannot format a volume larger than 32 GB in size using the FAT32
>> file system in Windows 2000. The Windows 2000 FastFAT driver can mount
>> and support volumes larger than 32 GB that use the FAT32 file system
>> (subject to the other limits), but you cannot create one using the
>> Format tool. This behavior is by design."
>>
>> With me so far? An arbitrary limit "by design" to force you to use
>> NTFS instead - for which good maintenance/recovery tools don't exist.
>
>I take it "Recovery Console" doesn't quite qualify?
Recovery Console isn't an OS, in that it can't run arbitrary apps.
The de facto mOS for XP is Bart PE.
So if Bart PE were like XP's DOS boot diskette, then Recovery Console
would be more like a bootable Norton DiskTools; i.e. a useful grab-bag
of specific fixes for specific problems.
Recovery Console is great for restoring default MBR code, rebuilding
Boot.ini, and restoring XP's partition boot code (e.g. as required
after a DOS mode Sys command, or installing a Win9x).
By duuuuuhfault, it can't access any volumes other than C:, and can't
copy files from C: to anywhere off C:, so out the box it is stone dead
as a *data* recovery tool.
You can, and IMO obviously should, apply three registry settings to
make Recovery Console slightly less useless for recovery of anything
other than XP bootability. These settings enable Set commands, and
here they are as a .REG file for this purpose...
<paste>
Windows Registry Editor Version 5.00
; Enable Set commands in Recovery Console (Set /? there for help).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Setup\RecoveryConsole]
"SetCommand"=dword:00000001
"SecurityLevel"=dword:00000001
</paste>
Now you can access volumes other than C: and can copy files off C: to
other places. There's *supposed* to be a Set command to facilitate
wildcards, but this doesn't work - "Recovery" Console has NO
equivalent to XCopy to copy entire subtrees, and no wildcards.
So yes, you can navigate into each directory through the handy Command
Line UI, and then copy off files one at a time, by explicit name.
Frankly, even the DOS ReadNTFS utility is more practical than this; at
least you can copy entire subtrees. Better is to load first the
working (as opposed to buggy) LFN TSR, then the free NTFS read-only
driver, from a DOS mode diskette boot; that lets you wildcard off
files with LFNs preserved, as ReadNTFS wouldn't do.
>(As I've said before, I've never used NTFS, so all I get is this information
>by the wayside. I'm still using FAT32 (and DOS, of course), as the
>fallback, and that's all I know).
Yep. What you really might enjoy, is Bart PE Builder :-)
Bill in Co.
Well, thanks for the reference. I've saved it just in case the day ever
comes when I am "forced" to go WinXP, although I can't see that day yet.
I'm still on Win98SE, and that's where I plan to stay, for as long as
possible!
Then again, by the time that becomes impossible (assuming it does), even
WinXP will be "gone", and the only thing out there will probably be
Vista-Bloatware (or something even worse), no doubt). Complete
Albatrosses. Bah, humbug.
Franc Zabkar
keyboard and composed:
>I wonder if there's an entry in the FAT or MBR or somewhere that holds
>the free remaining space so that it doesn't have to be computed all
>the time, and NDD can read that and see if it agrees with the actual
>clusters in use.
It's in the FAT32 volume boot record (as Chris stated in his prior
post).
http://cquirke.mvps.org/9x/scandisk.htm#BadFreeSpace
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.