 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 98 / General Topics / February 2007Cluster size and exploring the limits of FAT-32
This is an extension of recent posts concerning testing the practical 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. Boy, what a report (nice job)! 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. ___ > This is an extension of recent posts concerning testing the practical > limits of increasing the cluster count on FAT-32 drives under [quoted text clipped - 90 lines] > clusters, but not 31.2 million. Further testing is necessary to > determine the cluster-count limitation for NDD and SD. > Boy, what a report (nice job)! > Being I still use Win98 a LOT and have multiple drives much larger than [quoted text clipped - 97 lines] >> clusters, but not 31.2 million. Further testing is necessary to >> determine the cluster-count limitation for NDD and SD. nice info ...have you tried diskeeper to see if it would handle the defrag ? 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. 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: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/s upport/kb/articles/Q184/0/06.ASP&NoWebContent=1 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. 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? First, a little background: 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. I think this will be the last update, as I've made a rather important 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. >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: [quoted text clipped - 5 lines] >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: >http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/s upport/kb/articles/Q184/0/06.ASP&NoWebContent=1 >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 a.s? 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 [quoted text clipped - 3 lines] >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! >--------------- ---- --- -- - - - - > > One other thing. When booting directly into DOS with these > > various drives there is a delay when the first "dir" command [quoted text clipped - 6 lines] > 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. >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  SignaturePlease remove one 'i' from my address when replying by email. >> 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 [quoted text clipped - 51 lines] >> This link talks about why the max number of clusters is supposed to be >> 4,177,920: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com: 80/support/kb/articles/ Q184/0/06.ASP&NoWebContent=1 >> But that doesn't explain why I'm seeing DOS scandisk being compatible >> with 6.3 million clusters. [quoted text clipped - 9 lines] > 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? (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). On Sun, 25 Feb 2007 19:19:48 -0700, "Bill in Co." >http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com: >80/support/kb/articles/ >> The whole article smells whiffy... >> [quoted text clipped - 8 lines] > >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 :-) >--------------- ---- --- -- - - - - Saws are too hard to use. Be easier to use! >--------------- ---- --- -- - - - - > On Sun, 25 Feb 2007 19:19:48 -0700, "Bill in Co." http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com: >> 80/support/kb/articles/ > [quoted text clipped - 59 lines] > >> (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 :-) 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.