Ken said:
Ken said:
On 5/22/13 5:04 PM, J. P. Gilliver (John) wrote:
In message <
[email protected]>, Stan Brown
On Wed, 22 May 2013 13:08:20 -0400, richard wrote:
[]
Try partition wizard.
it does it all and even takes space from allocated drives if desired.
plus a lot more features windows DM never had.
And more than the great majority of people need. Windows 7's built-
in disk and partition management is fine for virtually everyone.
Does it still have the limitation earlier OS's ones had that there are
files it can't move, so if you want to drastically reduce the size of
the active partition you have to take several goes (and still may
not be
able)?
If it doesn't bother the user to do so, turn off System Restore and
Virtual Memory. That kills most if not all unmovable files. Shrink to
the desired size. Then turn on System Restore and Virtual Memory.
http://www.sevenforums.com/tutorials/2672-partition-volume-shrink.html
That appears to be a hypothesis, rather than an answer.
The evidence is, it stops at exactly 50%. Something is located at the
50% mark, that cannot be moved.
Try it yourself, then report back. Take an NTFS partition,
use the Shrink option in Disk Management, and see if the menu stops
at the 50% mark. Note that, if you've been using Raxco PerfectDisk,
the stopping point will no longer be at the 50% mark. It gets moved.
That's because, someone else reported (when I was researching this
a while ago), that PerfectDisk can fix it. I used an eval. copy
of that software, and it did indeed work. To bad the Raxco defrag
graphical screen would not stay visible after a defrag run, so I
could identify what got moved. It immediately disappears when the run
is finished.
For example, $MFTMIRR is mentioned here. It is preferentially placed
at the 50% mark. But I think in fact, it can be moved without harm,
to some other location. It could be, that in fact MFTMIRR is the
thing that sticks at the 50% point. You could still run into an
"unmovable" file, but it might be further towards the origin.
http://serverfault.com/questions/16...on-of-mftmirr-to-allow-resizing-the-partition
If Shawn actually knew the answer, there'd be a recipe for how to move
the offending object.
And there's probably *some* defrag tool out there, that even without
running a defrag, you might be able to display graphically, the
location of the various bits of metadata ($MFT, $MFTMIRR, and
so on).
Sheesh, Paul, I would have thought you, of all posters here, would have
heard of this. <grin>
It works.
I've done it a couple of times just for fun. Usually, I
just use EaseUS Partition Master Free. I've not had some of the issues
others seem to have had. I've no idea why.
And, I hate using Windows Disk Management. LOL
I posted that link because it was the first hit in my Google search that
listed it. Most hits are of the standard "you can only do 50%" variety.
But, since you are dubious, which is a good thing...
http://superuser.com/questions/88131/how-to-shrink-windows-7-boot-partition-with-unmovable-files
http://www.brandonchecketts.com/archives/how-to-shrink-a-partition-with-unmovable-files-in-windows-7
http://forums.lenovo.com/t5/Windows...ssue-with-partitions-in-Windows-7/td-p/237317
http://bartmaes.wordpress.com/2010/...when-shrinking-your-c-partition-on-windows-7/
Similar instructions for Vista...
http://www.howtogeek.com/howto/wind...ows-vistas-shrink-volume-inadequacy-problems/
What does all of this tell us? Windows is an extremely complicated
system. But there seems to be ways around the issue.
Kinda makes me wonder how Windows manages to work at all! LOL
In the systems I've done using Disk Management, the installs were new,
and/or things like IE were not used.
At the time I did my "research", there wasn't much previous research
to refer to. The only hint of a solution, was someone discovered
that a certain defragmenter could take care of everything for
you. And that was Raxco PerfectDisk.
I got stuck at the 50% point, and not at any other point. I didn't run
off, and try to figure out what other points people got stuck at.
The 50% point seemed to be pretty popular. The Pagefile was not disabled
(and I doubt very much Raxco did that either). And the SVI and VSS
wouldn't have been disabled either. As far as I know, if you were
to fool around with SVI and VSS, it would likely have to start
tracking changes all over again. (Would not pick up where it left off.)
A customer of Raxco would not be very happy, if there were side effects
from using the tool. As far as I could tell, I didn't see any side
effects. Everything worked the way it did, before the defragmentation
run.
I can tell you, that fooling around with System Volume Information is
dangerous. If I use the NFI utility, it lists everything except
a few entries. They're apparently of the "do not touch" variety. When I
used Linux to examine the files in System Volume Information, I found
some files that had zero checksums. The files were huge, but all the
sectors in them were zeroed. Apparently, this is something used for
tracking purposes, and they're not real files. Now, I didn't write to
any of the files in there. Just tried to read them. Well, it was all fun,
until I tried to reboot into Windows 7. I could not reboot. Three tries
with the repair, could not recover the system either. And I had to
restore from backup.
I don't know if I buy all the theories, due to the ability of a
defragmenter to move everything on its own. And I doubt that
tool goes around disabling stuff willy-nilly. I mean, depending
on the circumstances, you may not be able to disable the pagefile
(like, if there is more virtual memory currently occupied, than
physical memory present). You couldn't purge the Pagefile without
causing a problem. I guess that would take a reboot (to eject
all virtual memory usage), so the system could start fresh without
a pagefile.
I didn't attempt to "research this problem to the ends of the earth".
I was more curious at the time, about the claim that a defragmenter
could move everything. And it certainly looked that way. It's too bad
the graphical interface on the thing didn't stand still long enough, to
verify the thing at 50% was $MFTMIRR. Nothing else seemed to be a problem
for it. I shrunk a 320GB partition, down to 40GB, but the defragmenter
doesn't move $MFTMIRR all the way to the left. It takes a number of
runs of the defragmenter to complete the operation. And this was not
done for practical reasons - the practical solution is to use
one of the free partition managers to do the job. I was just curious
what the defragmenter could do or could not do. And I was impressed
with the job it did. Most defragmenters rely on the defragmentation
API, preferring to use the Microsoft code, so they can't be blamed
later for ruining a partition. And somehow, the defragmenter was able
to use that API to better effect, than Microsoft could.
If I'd been more methodical, I could have used NFI to keep track
of the location of stuff, and see what was causing things to get
stuck. But since I don't have any tools, to programmatically use
the defragmenter API, I couldn't really profit from using
that approach. All I can do with that is look, not affect anything.
And at the time, I wasn't exactly looking for research topics.
I actually wanted to shrink my C: partition, and adjust the
partitions on the disk. And the Windows capability, was stopping
me from getting the job done. I did just enough "research",
to complete my mission, and not an ounce more.
*******
This is from a previous post. It's not really very handy, but it
can give you a map of where things are. It was written quite a
while ago.
(nfi.exe is in this download - the missing "file numbers" in the log, would
seem to be equal to the number of open VSScache files)
http://download.microsoft.com/download/win2000srv/utility/3.0/nt45/en-us/oem3sr2.zip
To use it, try:
nfi.exe N: > N_sector_numbers.txt
Since virtually all of the partitions on this machine, have been
resized at one time or another, I can't really use the numbers
from anything here, as good examples of what to expect. The one
partition I did try, $MFTMirr is no longer dead center. And
that's because the partition has been bumped up in size a couple
of times, since it was first put in place.
HTH,
Paul
