Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.registry (
More info?)
> So, what about relocating Documents and Settings? No, I obiously
> wouldn't wish to point both os's to the same folder...However, can I
> relocate "each" systems' D 'n' C folder(s) out of the "system" partition?
You might not want to, for performance resons. But if you are not in a
hurry, I'll reply
I could think of a way, but chaces are (quite great, too) that you will
screw up the system not only beyond repair, but beyond recovery, too. Since
the folder is managed entirely by NT, reinstallation might not that the
settings under account correctly and nuke your folders. Also, you might not
be able to start your computer.
As a result, I urge you to *NOT* do this:
Quote from MS:
"NOTE: The following section provides information about a configuration that
Microsoft does not support. We provide this information for informational
purposes only; Microsoft makes no guarantee that this configuration
functions properly.
WARNING: Microsoft strongly recommends against renaming any system folder.
Catastrophic system failure or an unstable computer could result if you
rename system folders. If implemented, a backup should be made of the system
before attempting this procedure"
If you still feel suicidal (hehe), there is a way. Step-by-step info is
available from here:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:
80/support/kb/articles/Q236/6/21.ASP&NoWebContent=1
(KB 236621).
> A side quention not for "registry", (for for file_system?) but what is
> shell cache and dll cache?
Shell cache (shell icon cache, actually, if that's what you mean) is a
file in which the shell stores all the icons it extracted during the
session. Just like a normal cache, except that it's not kept in memory. The
thing is, when you pop a menu or browse the same folder over and over again,
speed is of the essence. Once cannot wait 3 seconds for a refresh to take
place, so last icons get cached. Also, for slow links and such, caching
icons is a good idea since extracting an icon requires reading and
interpreting the file for all files that have embedded icons and reading
icons from ass associated programs for associated documents.
You can imagine how long it would take to display a 10.000 logs folder.
What happens is the icon for .log gets cached and all others get the first
icon.
You can safely delete this file, as Windows will rebuild it (note it's
hidden so deleting might envolve special actions. The cache will get rebuilt
as you browse (expect slowdowns).
DLL cache is a storage for Windows SFC (you might want to document online,
lots to say and this is a dial-up link
. In short, SFC is a service that,
upon installation, service pack update, hotfixes, etc goes on and copies the
critical system files to this folder (drivers, system DLLs, etc). It
maintains a list of dates, sizes, positions, etc of these files and tracks
them. In the event that some get replaced (like installing an old W95
program that happily updates you dlls to 4.01, because they were the latest
at that point, without checking for version first), SFC nukes the bad copy
and replaces it with the original.
An event is logged (most of the times
, that the file "lalal.dll" was
replaced by a bad, vicious, man-eating version (4.01). As a result, the file
was replaced with the original to maintain system stability (6.0).
The amount of space allocated to the service can be configured, but I
recommend against it. SFC does a nice job, imagine having to reinstall every
time you install an older or ill behaved version. Bleah.
> My one system has a over 80 meg in the shell cache...the other is nearly
> empty. Both have nearly identical features and are up to date with Sp4.
Depends on configuration, installed software, blah blah. It'll grow with
time, but aside from disk space, it does not affect system stability. Just
leave it be.
> By creating that small FAT/boot partition, drive letters in hd0 (the
> "clone) are bumped up a notch.
Windows 2000 "tags" each drive and partition upon installation, generating
an unique ID depending on drive, system time, etc. If you replace the drive
with another one and boot, the drive letters will not be "notched" onwards.
This only happens on W9x (Wintendo). However, playing with bootable drives
is not a good idea.
Also, "hiding" and "active" is only effective for W9x and DOS, and, of
course, booting up. The NT5 disk manager can see and mount any partition,
even hidden.
> Clue me in to why I needed to
> create a FAT partition for DOS as I've described above?
An itch.
If you want to multiboot, the best idea is to boot to DOS 7+ (DOS mode of
W95/98). Unless you have a problem with that (I can't find such a reason,
but whatever). Advantages are that DOS 7 has FAT32 support.
Complex booting solutions, like 3-OS boot need to be thought up at the
very beginning. If you feel such an itch, create a 1-gig FAT partition at
the beginning of disk 1 and another 1 or 2 primary partitions, for the rest
of the OSs.
The partition's target is to hold boot loader for the best OS and, maybe,
a small DOS or Windows 9x. W98 installs and boots in about 300Mb, and 500
should be enough. This is to remain the boot partition. Install 24 on
primary partition 2 and XP on 3 if you want, but leave partition 1 as
bootable, FAT16.
If you didn't do this at beginning, it's more complicated, as W2k is not
as bare and stripped as W9x which doesn't even "boot", it just executes from
DOS. NT has partition signatures, path storage, etc. Also keeps SID, UID and
thus cannot be imaged and copied against another system unless (rather
complex) software prepares system registry while the system hasn't booted
yet.
My best bet would be to back it all up, re-partition, re-install and
restore. This will get you a robust multi-boot system.
Another bet is to use HDD0 for NT and HDD1 for DOS/9x. You can switch in
BIOS setup. Or install an advanced boot loader.
But this is meant to be expert domain. You are supposed to understand in
detail how MBR works, how partition tables are stored, how different OSs
store data and boot limitations. Partition and drive juggling without
through understanding of the inner workings will render your computer unable
to boot.
--
Andrei "Ndi" Dobrin
Brainbench MVP
www.Brainbench.com
Facebook
Twitter
Instagram