|
![](/i/fill.gif) |
Darren New wrote:
> Patrick Elliott wrote:
>> it will flat out *refuse* to consolidate the free space, even when
>> there is no sane reason to leave a handful of files scattered willy
>> nilly over the remaining disk space.
>
> There is a sane reason, actually. You just don't know what that reason
> is. :-) One possibility is that they're protected because they're
> branches of files carrying around the encryption key information.
> Another possibility is that they're locked open for writing.
>
No there isn't. Often, re-running the defrag will result in them moving
them anyway. The problem is simply that, unlike several third party
defraggers, the one in Windows **doesn't** consolidate free space, only
files. Once the files themselves are no longer fragmented, or there is
no available space, with the current configuration on the drive, to move
one of them, it stops. This happens **even if** it could have
consolidated some of the free space and thus "gained" the space needed
to move the file it refused to defragment. I know, I have played with
the thing enough, and re-run in multiple times, so I am well aware what
it will and won't do. And it simply won't move some files (even if it
clearly labels them, in its display, as "movable", if it doesn't need to
do so, since it doesn't treat "free space" as fragmented, and in need of
correction.
The stupid thing about this is.. assuming the files are mostly stable,
and won't change, like the OS partition, it actually makes it "more"
likely that any new files installed will "become" fragmented, the moment
you write them, since all the free space gaps are still there.
>> And, that is the problem. If you need to defrag something like the
>> page file, during boot, how do you do that, if it won't move the
>> stupid files that are in the way? :(
>
> Copy those files to a different disk, delete them, defrag, copy them back.
>
Ah yes.. Because it "tells you" which files they are, so you can do
that, and they will never be something critical, which you can't move
someplace else first. And, as I pointed out above, **this doesn't fix
anything*, since it won't consolidate free space.
>>> The only XP memory limits I know of was running into the 4G boundary.
>>> And apparently that's a licensing thing - seems XP x86 is happy to
>>> use however much memory you put in there, except that Microsoft tells
>>> it not to.
>>>
>> Yeah. I know. But, the hack requires changing the boot.sys file.
>
> Different hack, I suspect.
>
Don't think so... Though, maybe there is some system file you can
replace, or something, that does it automatically. All I know is that
one version involves adding a flag to the startup for the OS, and that
is, I think, in the boot.sys file.
>> They managed to make the OS smart enough to boot anyway, if its
>> damaged/missing (mine is missing for some reason), but didn't include
>> any way to rebuild it, if you lost/mangled it. So.. No file, no clue
>> how to write it, and therefor, no means to override the setting.
>
> LMGTFY. http://mirror.href.com/thestarman/asm/mbr/bootini.htm
>
Uh, yeah. And I am assuming my system is vanilla enough I could do that
manually, but I would still prefer something that could look at my
existing install and just recreate the file, so I know it is correct. I
have no clue what any of the partition, etc. stuff is in there, and I
don't want to spend an hour figuring it out. ;)
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
![](/i/fill.gif) |