J. P. Gilliver (John) said:
and studying C: there). If you were to uninstall the games
directory, all that would happen, is the hard link count would
[]
What do you mean by "uninstall the games directory" - delete it? To me,
uninstall is something I can only do with software. However, usages
change, and I'm glad to yield to a new usage, once I know what it is.[/QUOTE]
If you go to Add/Remove, and look at Windows components, there
were options in previous OSes, to add or remove features. For
example, on my current WinXP Pro machine, I have the option of
installing IIS if I want (web server).
The difference, as I see it on Windows 7, is the store concept,
where even software you're not licensed to use, is kept
and maintained in the store. There have been various discussions
about "space saving", and the difference in this case, is the
extensive usage of hard links. Data clusters in the file system,
don't get "deleted", unless the reference count to them, drops
to zero. A file from the store, has one hard link if it isn't being
used. A typical file that is in usage, has four hard links. That
means, you can find a file name pointing to that data, in four
different directories. To store the file, only takes one unit
of data storage, as the four file pointers are pointing to the
same data. So there aren't four copies, only one set of data
and four file names - if you overwrite the data, all four
files appear to change at the same time - thats what the
hard link gets you.
(Experimenting with hard links) <
[email protected]>
http://al.howardknight.net/msgid.cgi?STYPE=msgid&MSGI=<[email protected]>
So what I'm saying is, by all means, do the experiment, go to
Windows Components and "remove" some software you dislike. But
by doing so, don't expect Windows 7 to yield you a big space
saving. Because the *tendency* is for Windows 7 to hold onto
stuff to the bitter end. Since the Windows Components also
allows you to "reinstall" stuff, the original files can't
really be gone. And that tells me, that the stuff must still
be there in the store.
When I looked at the store, I could find files with "Ultimate"
in their name, and they had one hard link to them. On my
"Premium" laptop, that tells me they aren't being used. But
if I were to purchase an Anytime Upgrade, I would be licensed
to use the features, and then, additional hard links would be
added, to link those files into the real, operational OS folders.
The actual number of files involved (to get Ultimate), isn't
that large, so there isn't that much of a penalty for having
all versions of the OS, in the store.
These are things I've determined by experimentation, not by
reading them in a book, which is why I encourage others
to have a look for themselves and see how it works. There
have already been complaints from IT professionals, about
the ability to keep Windows 7 trim and svelte, and it would
mainly be from people who run virtual machines. And that's
where I got the idea, that the design intent is to hold
onto things. There didn't seem to be any attempt by Microsoft,
to offer tools that could remove files where there was
no longer a dependency. And that leads to a (relatively slow)
growth of the space needed to store C:, as new security updates
and the like, come in. A Service Pack, does contain info on
stuff that can be removed, but doesn't check dependencies on
everything, only the Service Pack related files (i.e. precomputed
removal of some sort - not a generic cleanup).
I did my experiments, because I wanted to see what kind of
impact SP1 has. And it wasn't that big a deal.
Making .vhd files is necessary, because Windows 7 didn't include
reworking Explorer, to show users how much space was really being used.
(Hard links can easily get double counted, if you just use Explorer.)
And making a .vhd, the size of the .vhd is an accurate representation
of how much space is needed on C:.
As an example, in that archived post above, I found these four files.
Program Files (x86)/Reference Assemblies/Microsoft/Framework/v3.0/System.Workflow.Runtime.dll
Windows/assembly/GAC_MSIL/System.Workflow.Runtime/3.0.0.0__31bf3856ad364e35/System.Workflow.Runtime.dll
Windows/winsxs/x86_wwf-system.workflow.runtime_31bf3856ad364e35_6.1.7600.16385_none_64f133bd015a8f4f/System.Workflow.Runtime.dll
Windows/winsxs/msil_system.workflow.runtime_31bf3856ad364e35_6.1.7600.16385_none_d7f57c8120b07553/System.Workflow.Runtime.dll
Those four files, point to the same set of data clusters. The first
link, is the one used by the OS. The two at the bottom, are
in the store.
If I went to Explorer, to the folder holding that file, and did
properties, I'd get the same "size" for each file. If I added
those numbers together, I'd get "4*size", which is 3 times
larger than it should be (since there is only one set of data
clusters for the four "files"). So when people blithely select
"Properties" on a folder in Windows 7, they're going to get
the wrong answer (as long as there is at least one hard linked
file in the folder). I see arguments all the time about "my blahblah
folder is 6GB", when in fact you simply can't use Explorer
properties and get an accurate answer, with out a *great*
deal of care. And "hard links", without modifying the displayed
info in Explorer, is what leads to that inaccuracy and lack of
ability to add numbers together and get a number equal to the
file system size.
And that's why I use .vhd, to measure changes. It's clumsy, but
I don't have to do any arithmetic or accounting to get info. If
you want to know how much impact a change has made to C:, do a
backup, then check the size of the resulting .vhd file. As the
example hard linked file above, only takes "1*size" in a .vhd
(plus the metadata for the four file pointers). The .vhd only
stores just enough info to accurately reproduce the file system.
Paul
