More on hard links


After posting my original entry on how hard links work, a number of comments were made requesting clarification.  The original blog posting is below:

http://blogs.technet.com/b/joscon/archive/2011/01/06/how-hard-links-work.aspx

To his credit Joseph has been asking me about revisiting this topic for months.

I think part of the confusion about how hard links work revolves around the difference between what the Windows shell shows us and what is really happening in NTFS.

Here we have a couple of directories roughly displayed as the Windows shell would show it to us. The diagram gives the impression that the files exist inside their respective directories. In the following example there are two instances of ‘File1.txt’.

clip_image002

If we look under the hood we can see that each directory and each file has its own entry in the Master File Table (MFT).

clip_image004

As you can see from the above diagram a file isn’t really ‘inside’ the directory. The directory just has a pointer to the location where the file exists in the MFT. Using the diagram from my old blog entry we can see the three part relationship between the file and the parent directory.

clip_image005

1. The directory has an index entry that tells us the MFT address for the child file.

2. The file has a file name attribute that tells us what the file record number of the parent directory.

3. The file has a link count that tells us that it only has one parent directory.

If I were to dump out the metadata for a directory, it would only tell me the location in the MFT for the files that are related to the directory. No part of the actual file is actually IN the directory. If you were to look at the actual addresses in the MFT they might appear like this…

0025 – Dir1

005a – Dir2

100a – File1.txt

15ab – File1.txt

Dir1 would have an index entry that included a reference to 100a (File1.txt). And Dir2 would have an index entry that included a reference to 15ab (the second instance of File1.txt).

Now let’s look at a hard linked file. The shell part isn’t really going to appear differently.

clip_image006

But when we add in what NTFS is really doing you can start to see a difference.

clip_image008

Instead of having two copies of the same file, the index entries in both directories point to the same address in the MFT for the child file.

The three part relationship also changes. The file becomes aware that it is referenced by multiple directories.

clip_image009

1. Each directory has an index entry that tells us the MFT address for the child file.

2. The file has two file name attributes. One for each parent directory.

3. The link count is incremented to 2h.

And finally if we looked at the addresses in the MFT, they might look like this….

0025 – Dir1

005a – Dir2

100a – File1.txt

100a – File1.txt

Hopefully the new diagrams combined with the older ones will help you to properly visualize what NTFS is doing. To really get your head around it is essential to stop thinking about ‘the real copy of the file’ or ‘the file being IN the directory’.

Finally, when looking at the two link diagrams side-by-side…

clip_image010

…you might be asking yourself, “How is the hard link different than the normal link relationship?”

The answer is that it isn’t. Technically EVERY file is hard linked. We just reserve the term for talking about files that have more than one directory linked to them.

Now moving forward, let’s look at some real world information. Simple names like Dir1 and File1.txt are fine to start off with but we need to relate it to what’s in the Windows directory. We can do this with some easy substitutions.

Dir1 = c:\windows\system32

Dir2 = C:\Windows\winsxs\amd64_microsoft-windows-securestartup-service_31bf3856ad364e35_6.1.7600.16385_none_c09aa5b3bec88beb

File1.txt = bdesvc.dll

And I kept them color coded to keep it easier to follow.

I dumped out the metadata for the file bdesvc.dll. I’ve simplified it for readability but you can see that it has two file name attributes, one that lists a parent directory of 280b and one that lists a parent directory of 124d.

_FILE_NAME {

_MFT_SEGMENT_REFERENCE ParentDirectory {

ULONGLONG SegmentNumber : 0x000000000000280b

USHORT SequenceNumber : 0x0001

….. FileName : "bdesvc.dll"

_FILE_NAME {

_MFT_SEGMENT_REFERENCE ParentDirectory {

ULONGLONG SegmentNumber : 0x000000000000124d

USHORT SequenceNumber : 0x0001

….. FileName : "bdesvc.dll"

And of course the metadata also showed the higher ‘link count’, meaning that there are two links pointing to the file record.

USHORT ReferenceCount : 0x0002

I dumped out the metadata for both 280b and 124d and found that they were the two directories that I’d expected (system32 and amd64_microsoft-windows-securestartup-service_31bf3856ad364e35_6.1.7600.16385_none_c09aa5b3bec88beb).

Joseph brought up an example of what would happen if a private hotfix were installed. Depending on how that was done it would sever the hardlink and put a new version of the file in the system32 directory. So we would end up with two copies of the file. The old one would still be under amd64_microsoft-windows-securestartup-service_31bf3856ad364e35_6.1.7600.16385_none_c09aa5b3bec88beb. And the new one would be in the system32 directory.

Later if you were to run ‘SFC /scannow’ Windows would remove the new copy and establish a new hard link using the file that was still stored under WinSxS.

When SFC runs it compares a checksum of the file against a copy of the checksum that Windows has squirreled away somewhere.

However if the one and only file were to become damaged, then SFC would fail with an error…

“Windows Resource Protection found corrupt files but was unable to fix some of them.

Details are included in the CBS.Log windir\Logs\CBS\CBS.log.”

The other main concern was how to view disk space. That’s actually the easy one.

clip_image011

See the pie chart? Its correct.

Okay, I’ll explain it a bit more in-depth than that.

There are two ways to view how much free space. The first way it to use the pie chart. The information in the pie chart actually comes from a special metafile named $BITMAP. This file maintains a list of all the clusters of the volume and if they are in use or not. When a file needs space, $BITMAP is queried to see what is free. When space is allocated, $BITMAP is updated to show that the allocated clusters are now in use. Keep in mind that $BITMAP doesn’t track what files own what clusters. It only tracks what clusters are in use. So when we draw the pie chart, we just query $BITMAP to find out how many clusters we have and how many are free. This is also why the pie chart is populated so quickly. We just have to read a single file to build the chart.

The second way to get free space is what I refer to as “the wrong way”. That is to open a CMD prompt at the root directory and do a ‘dir /s’. This will list all the files on the volume that you have access to and add up the sizes at the end. This method is just plain wrong. A big part of why it is so wrong is that hardlinked files will get counted twice….once for each directory that is linked to them. The other big reason is that the DIR will only list files that you have access to. Files in the System Volume Information directory will not be included. That’s a problem because that’s where the VSS snapshots are stored. And the special metafiles that are hidden from the user are also not listed in the total. So the space used by your MFT will not be listed, your security file ($SECURE) will not be listed, and so on. There’s just too much to take into account to get a truly accurate total by adding files together.

I know it sounds like it should work but there are factors involved in storing your files that most people just don’t know about. As an example, Windows 2003 reserved about 12% of the volume for the MFT to have room to grow. So if you had a very large volume with just a few files, you might wonder where all your space was.

The take away from that is what I tell my customers and coworkers, “Trust the Pie Chart”.

I hope this has been helpful.

Robert Mitchell

High Availability

Enterprise Platform Support

Enjoy my writing? Here are other blog entries that I have authored…

http://blogs.technet.com/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx

http://blogs.technet.com/askcore/archive/2009/12/30/ntfs-metafiles.aspx

http://blogs.technet.com/b/askcore/archive/2010/08/25/ntfs-file-attributes.aspx

http://blogs.technet.com/b/askcore/archive/2010/10/08/gpt-in-windows.aspx

http://blogs.technet.com/b/askperf/archive/2010/12/03/performance-counter-for-iscsi.aspx

http://blogs.technet.com/b/joscon/archive/2011/01/06/how-hard-links-work.aspx

http://blogs.technet.com/b/askcore/archive/2011/04/07/gpt-and-failover-clustering.aspx

http://blogs.technet.com/askcore/archive/2010/02/18/understanding-the-2-tb-limit-in-windows-storage.aspx


Comments (39)

  1. Anonymous says:

    I dont believe Mark is covering this in Windows Internals but I can certainly ask.  As for the KB, we have a few that reference how the component store works and the role that hard links play in that process.  I'm not sure I see value in having a super technical review of hard links and the component store in a KB however, maybe a whitepaper or something along those lines but this isnt really something that we get asked a lot of questions about.  Hard links arent new so there has been plenty of time for customers to ask about them 🙂

  2. Anonymous says:

    @Dean;

    Well I will play devil's advocate here, just because you see that type of content as important also doesnt mean that the documentation that exists for it today isnt sufficient.  I dont mean to diminish your point but realistically we could document the CBS mechanisms to death and in the end it really wouldnt mean much because there isnt anything externally that customers can do with it.  If we had a public API for CBS then yes, we should have really technical documentation as to what can and cant be done with the component store and the servicing stack.  But right now, this is internally consumable Microsoft IP.

    I have various links throughout the blog to different articles on CBS and how specific portions of it work and why.  We also have trouleshooting content online and in the KB.  Those are the reasons I dont see an in-depth technical reference on this material as valuable right now.  Also, content creation costs money because it has to be localized, vetted for accuracy, published to various resources, etc.  I also take those things into consideration when I determine the value to both yourself and the company I work for.

    Aside from knowing how the servicing mechanics work, what else would you do with that information?

    –Joseph

  3. Anonymous says:

    @Dean

    Windows XP HAD an folaer with backups, This was the DLLCache folder which sfc used to restore files.

  4. Anonymous says:

    I'll check into performance, I havent seen any issues with the new layout though, perhaps others can comment.

    As for the post installation piece, the component store doesnt really act as a last reference, thats what the winsxsbackup folder is for.  The OS structure is completely different due to the way the componentization of the OS works.  The on disk structure is fundamentally the same though.  Maybe I am missing something in the question though.

    –Joseph

  5. Anonymous says:

    The component store backup directory is there in the event that one of the files in the component store is also corrupted, it holds the manifests for the different components.  Its there for redundancy.  All of the payload is still in the component store itself.  

    You can see that the backup folder isnt hardlinked to the component store using fsutil.  For example, if you check the kernel for hard links, you'll get two:

    C:>fsutil hardlink list c:windowssystem32ntoskrnl.exe

    WindowsSystem32ntoskrnl.exe

    Windowswinsxsamd64_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7601.17640_none_ca31f809cade8847ntoskrnl.exe

    But if I needed to recover the manifest that tells me whats in that payload, then I could potentially use the backup folder to do so (if it were corrupted in the component store).

    Directory of C:WindowswinsxsBackup

    08/16/2011  03:00 AM         5,561,216 amd64_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7601.17640_none_ca31f809cade8847_ntoskrnl.exe_0fb0ab79

    08/16/2011  03:00 AM         3,912,576 x86_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7601.17640_none_6e135c8612811711_ntoskrnl.exe_0fb0ab79

                  2 File(s)      9,473,792 bytes

    You can see that I have backup manifests for the 32 and 64 bit kernel there in case I need them.

    –Joseph

  6. Anonymous says:

    Dean;

    To answer number six, no thats not the only reason the component store is there.  The ability to not need media is just a side effect of the componentization of the OS.  The component store is there, quite frankly, because that was a design decision made when developing Windows. It allows for components and updates to be shipped in a more efficient manner to customers and a more streamlined development process internally for creating new code.

  7. Anonymous says:

    It's not used as a backup, think of it more as a flat directory of the files (similar to what you would have done in XP when you wanted the installation files locally).

  8. Anonymous says:

    The backup folder inside WinSxS is used to get Windows working again if some critical files are corrupted which Windows needs to boot into safe mode. This is called Windows Resource Protection:

    "WRP copies files that are needed to restart Windows in the cache directory located at %Windir%winsxsBackup. Critical files that are not needed to restart Windows are not copied to the cache directory. The size of the cache directory and the list of files
    copied to cache cannot be modified."

    msdn.microsoft.com/…/aa382530%28v=vs.85%29.aspx

  9. Anonymous says:

    Dean;

    The installation methods are very different actually.  XP was a flat file copy process, we had an ordered list of files that were expanded onto the disk one at a time.  Vista ++ explodes the install.wim to its given directory structure but it's not a flat file copy.  The foundation packages are layed down first and then the SKU differentiating packages that make up your Windows edition are layed down.  From there they are parented with the servicing stack and then projected to the appropriate directories using hard links.

  10. Anonymous says:

    Dean,

    Actually I’m glad that Joseph kept reminding me.  I just had a great deal of content creation in the last 6 months.  So my time was stretched pretty thin.

    > Although I still want to know why your first example where there is more than one entry in the MFT for a file would ever happen.

    The first example was of two files in two different directories that just happened to have the same name.  Since each instance of the file is unique, each gets an entry in the MFT.  Hardlinks are the exception.  It allows you have to one file that is seemingly in two or more places at once.  As such it only gets a single entry in the MFT.

    I can’t address your installation question.  That’s a bit outside my area.  Perhaps Joseph can handle that one.

  11. Anonymous says:

    1) Windows is divided into packages/components starting with Vista. The manifest describes where each file of the component/package is stored.

    Example of the manifest of the Microsoft-Windows-Advapi32 component:

     <file name="advapi32.dll" destinationPath="$(runtime.system32)" sourceName="advapi32.dll"

    So the advapi32.dll is stored in the WinSxS folder:

    "C:Windowswinsxsamd64_microsoft-windows-advapi32_31bf3856ad364e35_6.1.7600.16385_none_3f3d4351a032bf57advapi32.dll"

    and mapped according to the manifest to the system32 folder:

    C:WindowsSystem32advapi32.dll

    2) yes, only the boot critical files are backuped there.

    3 and 5) yes, sfc uses the files from backup to get Windows working. If sfc can't repair non boot critial files you get a warning in the CBs.log because the backup folder only contains the files which are needed to get Windows running.

    So if you hack the nt kernel.exe sfc can repair it because the file has a backup. If you modify the Aero theme or customize the MMC Snapin (MSC) sfc can't repair them because those non critical files have no backup. You can get the clean files from a different Windows or run the System Update Readiness Tool KB947821.

    6) WinSxS contains all files. The files that are used are linked to the destination folders according to the manifest

  12. Anonymous says:

    Drewfus,

    There is a CMD way to get the free space that does use the $BITMAP method.  

    'fsutil volume diskfree c:'

    Just be aware that if you go to compare the GUI and CMD methods you have to do them quickly.  Free space, especially on your system volume is in constant flux.

    Having a command like what you are suggesting wouldn’t work currently because the $BITMAP file is per volume, not per directory.  For your suggestion to work we would have to add a $BITMAP attribute to every directory….and that would end up being an extreme performance hit.

  13. Anonymous says:

    LOL, good suggestions Drew.  I'm not sure what the content plans around Win8 are right now but I will see what I can do to get this feedback in front of the right group(s) internally here.

  14. Anonymous says:

    I'd thought about that but we were trying to keep that KB as informative without being overly technical as possible to allow for easier reading.

  15. xpclient says:

    Nice to know that information. I wish all methods in Explorer and cmd-line tools of reporting free disk space and calculating size accurately were updated in Windows 8 so there are no discrepancies and no inaccuracies.

  16. Drewfus says:

    Thanks Robert, very informative.

    "See the pie chart? Its correct."

    Yes, but should the pie chart be a bar chart instead? simplecomplexity.net/pie-chart-arguments

    "The second way to get free space is what I refer to as “the wrong way”. That is to open a CMD prompt at the root directory and do a ‘dir /s’."

    It's odd that the GUI interface is accurate, and the CLI isn't. How about a new command?

    > bitmap <drive>[path] [/free | /used | /both] [/units:<Bytes|KB|MB|GB|%>] [/b]

  17. Dean says:

    "To his credit Joseph has been asking me about revisiting this topic for months."

    It was me who kept bugging Joseph who then kept bugging you. So you can smack me.

    THANK YOU THANK YOU THANK YOU THANK YOU for finally doing this. And a big thanks to Joseph for continuing to bug you.

    You know the one statement that really cleared things up for me ?

    "We just reserve the term for talking about files that have more than one directory linked to them."

    To you guys that statement is nothing. No big deal.

    But to the rest of us it is a BIG deal. Why ? Because it clarifies the technical terminology. Terminology clarification makes a HUGE difference in trying to understand something. This needs to be done much more often in Microsoft documentation. I may be wrong but I think you are the only person to have ever made that statement in all of the talk about hard links. And before you made that statement I was going to ask why the hardlink method wasn't used since the NT 4.0 days because it appears to save a lot of space in the MFT. Although I still want to know why your first example where there is more than one entry in the MFT for a file would ever happen.

    It also seems to me that having only one entry for a file in the MFT is not as safe as having multiple entries in the MFT because if the one entry gets corrupted the file is lost.

    Now, I want to make sure that I finally understand how this relates to the WinSxS directory.

    The WinSxS directory has entries ( index entries ) ( for each subdirectory in WinSxS ) that point to metadata that has the linked list of clusters of files that were laid down when windows was installed to the hard drive. The clusters should have no relationship to the way the files are laid out in the WIM file. There is one entry ( index entry ) for each file in WinSxS. When Windows is being installed to the hard drive AFTER the WinSxS directory structure is laid down to the drive the install routine then goes back and creates the Windows directory folder structure and populates the subdirectories with index entries that point to whatever files that subdirectory should be shown to have when looking at it in Explorer. This is different from the way XP was installed because when XP was installed the install routine just laid down the files to the hard drive and then populated the directories with entries ( index entries ) that pointed to the files metadata.

    So in reality the only difference between the way it was done in XP and the way it is done in Windows 7 ( and Vista but we won't count that 🙂 ) is that in Windows 7 the WinSxS directories act as the last reference to the files as a backup.

    Correct me if I'm wrong on anything.

  18. Dean says:

    When I said:

    "So in reality the only difference between the way it was done in XP and the way it is done in Windows 7 ( and Vista but we won't count that 🙂 ) is that in Windows 7 the WinSxS directories act as the last reference to the files as a backup."

    I meant AFTER the files were laid down and the installation was finished. So am I right ?

    Also there is a major problem with your new site design. Once you get past about 5 lines of comments everything slows WAY down and you can only type one character a second and after about 8 lines you can't see what your typing anymore but it's there.

  19. Dean says:

    I thought the whole point of the WinSxS directory was to act as a backup of the installation files to be able to replace them from the WinSxS directory ( using hard links ) in case they needed to be replaced for some reason. In this regard Windows 7 would be different from Windows XP in that Windows XP had no directory installed that contained a backup of the installation files.

  20. Dean says:

    So the winsxsbackup directory is the backup and is where the SFC gets it's files from to hardlink ? The WinSxS directory is just an installation source like copying the XP CD to the hard drive ? If so why can't the WinSxS directory also act as the backup ? Why make another redundant directory just for backup ?

  21. Dean says:

    Crying 🙁

    1) Can you give a definition of "manifest" ? One that's easy to understand.

    2) The %Windir%winsxsBackup directory is ONLY for backing up the most critical windows files needed to get windows booted ?

    3) SFC DOES NOT use the %Windir%winsxsBackup directory ?

    4) I thought WRP was for ALL of the windows files not just the most critical ?

    5) Where does the SFC get it's replacement files from ? Yes, I know the "replacements" are hard links.

    6) The WinSxS directory is ONLY there for installing OS components that were not chosen during the initial installation so that you do not have to put the DVD in ?

  22. Dean says:

    I just looked at the WinSxSbackup folder on my Windows 7 installation and it contained 650 Amd64 manifest files. I then looked at the WinSxSmanifests folder and it contained 9,976 Amd64 manifest files. So your statement about the WinSxSbackup directory only containing the most critical manifests and files seems to be valid.

  23. Drewfus says:

    @RM: Thanks Robert. Yeh the bit about $bitmap per directory was a bit brainless.

    If i use 'fsutil volume diskfree c:' and divide the total # of bytes by 1024, i get:

    > Invalid number.  Numbers are limited to 32-bits of precision.

    This is on 7_x64. Isn't that just a little bit embarrassing? I could use Powershell – except in WinPE, which is where a calculation like MB freespace might be most useful. Windows 8/PE?

  24. Drewfus says:

    @joscon: "Vista ++ explodes the install.wim to its given directory structure but it's not a flat file copy.  The foundation packages are layed down first and then the SKU differentiating packages that make up your Windows edition are layed down.  From there they are parented with the servicing stack and then projected to the appropriate directories using hard links."

    Interesting. Questions:

    1. So by 'given directory structure' you mean relative to %systemroot%winsxs ?

    2. Would it be accurate to think of %systemroot%winsxs as the true installation root, %windir%system32 as the 'working backup', and %systemroot%winsxsbackup as the boot critical backup?

    3. How does a manifest determine foundation verus SKU package?

    4. Is 'parented with servicing stack' outlined somewhere?

    5. Is the projection of packages achieved simply by calling SFC.exe /scanNow?

    Dean is correct about the comments field. I got dizzy writing this. 🙂

  25. Dean says:

    This:

    msdn.microsoft.com/…/aa382541(v=vs.85).aspx

    states:

    "Protected files not critical to restart Windows are not repaired."

    and another KB said that it only works on "non modifiable" system files.

    So that is also verified.

    The KB that got me thinking that ALL OS files were scanned and protected is KB929833 that says "The sfc /scannow command scans ALL protected system files and replaces incorrect versions with correct Microsoft versions."

    but you have to know ahead of time that ALL means ALL of the WRP files which are NOT ALL of the files but ALL of the critical files that are protected by WRP. I think I am getting the hang of writing definitions in circles. Maybe I should apply for a job
    at Microsoft now.

  26. Dean says:

    So from my "crying" posting I still need question 6 answered.

  27. Dean says:

    "5. Is the projection of packages achieved simply by calling SFC.exe /scanNow?"

    With what I have learned here I think I may be able to answer that one myself. I think the answer would have to be no because the SFC only works with the most critical boot files and not ALL the OS files.

  28. Dean says:

    "5. Is the projection of packages achieved simply by calling SFC.exe /scanNow?"

    I'm really going to go out on a limb here and say it's done by the Trusted Installer Module.

  29. Dean says:

    "To answer number six, no thats not the only reason the component store is there.  The ability to not need media is just a side effect of the componentization of the OS.  The component store is there, quite frankly, because that was a design decision made when developing Windows. It allows for components and updates to be shipped in a more efficient manner to customers and a more streamlined development process internally for creating new code."

    That actually makes sense now. You said:

    "The installation methods are very different actually.  XP was a flat file copy process, we had an ordered list of files that were expanded onto the disk one at a time.  Vista ++ explodes the install.wim to its given directory structure but it's not a flat file copy.  The foundation packages are layed down first and then the SKU differentiating packages that make up your Windows edition are layed down.  From there they are parented with the servicing stack and then projected to the appropriate directories using hard links."

    So, if you have to go through the trouble of laying out the WinSxS directory structure during install time then you may as well leave it there for some extra benefits.

    I think I finally understand the WinSxS mystery now.

    Whooo Hoooo !

    Thanks for the patience.

  30. Dean says:

    "To answer number six, no thats not the only reason the component store is there.  The ability to not need media is just a side effect of the componentization of the OS.  The component store is there, quite frankly, because that was a design decision made when developing Windows. It allows for components and updates to be shipped in a more efficient manner to customers and a more streamlined development process internally for creating new code."

    That actually makes sense now. You said:

    "The installation methods are very different actually.  XP was a flat file copy process, we had an ordered list of files that were expanded onto the disk one at a time.  Vista ++ explodes the install.wim to its given directory structure but it's not a flat file copy.  The foundation packages are layed down first and then the SKU differentiating packages that make up your Windows edition are layed down.  From there they are parented with the servicing stack and then projected to the appropriate directories using hard links."

    So, if you have to go through the trouble of laying out the WinSxS directory structure during install time then you may as well leave it there for some extra benefits.

    I think I finally understand the WinSxS mystery now.

    Whooo Hoooo !

    Thanks for the patience.

  31. Dean says:

    I would cut and paste some of this stuff into a KB article maybe titled "Explaining the Mystery of the WinSxS Directory"

    I would use the two postings on the Hard Links and some of the comments and answers modified for KB format.

  32. Dean says:

    Which KB ?

    And if there is already a KB then there needs to be an additional one. One KB that's not to technical and one that I want which is very technical. After all I think your web servers could handle the addition of one more document without running out of drive space.

  33. Drewfus says:

    @Dean: "And if there is already a KB then there needs to be an additional one."

    Perhaps a white paper would be more appropriate than the KB? Maybe the upcoming edition of Windows Internals will have a nice long chapter on this entire subject.

    http://www.amazon.co.uk/…/ref=sr_1_7

  34. Drewfus says:

    Thanks for that Joseph. In reference to a white paper, i mean something that covers essentially everything you've blogged about. Servicing stack architecture, component store structure, Windows Update, logs, troubleshooting, command line tools, changes from pre-Vista, etc. Just everything please!

    Re Windows Internals, that excellent text is not quite over my head (in a lot of places), but it does go into enormous low-level detail, often in areas where i'm really only interested in an overview. That's not at all a criticism, but it means that between the Resource Kit text and WI, there is something of a gulf. My old XP RK text does not suffer from this, but now Windows is so vast that the RK for Win7 is more of an extended user manual than a technical text. My request for Windows 8 and equivalent Server release, is that the RK becomes two volumes – a day-to-day operations volume, and a technical "behind the scenes" volume, with a nice discount if you buy both together! Oh, and the second volume will include chapters by Joseph Conway and Robert Mitchell. 🙂

    Don't want much, do i?

  35. Dean says:

    " I'm not sure I see value in having a super technical review of hard links and the component store in a KB however"

    Just because YOU don't see the value doesn't mean that there isn't one. This is what I keep trying to get through the heads of you people who work for Microsoft. Just because all of you understand a subject why do you have the need to make sure there are resources out there for everyone else to be able to understand them ? And it should be FREE not in a pay for book.

    I don't understand why this is always like pulling teeth.

    Can you list the current KB articles ?

  36. Dean says:

    And it's not just about the hard links. It's also about the backup directory and how the SFC works with the WinSxS directory. It all needs to be in ONE document that CLEARLY lays it all out.

  37. Dean says:

    If you want I can do a draft of what I think it should look like and send it to you.

  38. Drewfus says:

    @joscon: "Aside from knowing how the servicing mechanics work, what else would you do with that information?"

    Other than as a troubleshooting aid, understanding how a new technology works can help people feel comfortable with that technology, and in the case of Windows 6.x, contribute to overcoming this issue:

    apcmag.com/calling-time-microsofts-chris-jackson-on-retiring-win-xp-ie6-and-office-2003.htm

  39. Dean says:

    Your thinking like a programmercoder again. I'm speaking for all of the network administrators.

    Network administrators don't care about API's and manifests and mechanisms and all that other blah blah blah coder crap. Not that it's not cool but we have no interest or need for it. What we need is CLEAR and PRECISE documentation so that we can understand why something is there and how it works so that when it doesn't work we can feel CONFIDENT that we know what should be done to fix it or if what we have tried for a fix worked or not. We also need to clearly understand what we should not ever touch and WHY. You can try all you want to automate fixes but we are no where near the time where an admin isn't needed to fix things yet.

    It took me months to finally understand the WinSxS directory from your blog and I'm sure I'm not the only admin who had trouble with it. And that's only one subject of many. The programmers out there probably got it in five minutes. The problem is that the programmers are not the people who install, set up and maintain servers and desktops. And they don't want to. It's not their thing, any more than coding is an admins thing. It's the admins who do all of the installing, maintaining and troubleshooting and if it wasn't for them the programmers would be out of a job because thier product wouldn't be purchased.

    So when I say that we need such and such documentation I mean we administrators need it because we need different wording from what the programmers need.Sometimes we need diagrams to go along with the words. Having it spread across your blog isn't good enough. It needs to be in a self contained document that can be found by searching the KB or white paper list because those are searched much more often than blogs are.

    "Also, content creation costs money because it has to be localized, vetted for accuracy, published to various resources, etc."

    Whatever the cost would be it's already paid for by the $39 Billion or whatever it is that Microsoft makes a year.