Patrick Elliott wrote:
> No there isn't. Often, re-running the defrag will result in them moving 
> them anyway.

I don't know if you're talking XP or Vista, but there are things in Vista 
that are locked open until you modify enough stuff on disk that it rolls out 
of the cache and gets closed. System snapshots spring to mind.

> The problem is simply that, unlike several third party 
> defraggers, the one in Windows **doesn't** consolidate free space, only 
> files.

Bull. You can watch it happen yourself. It shows up in the status line of 
the GUI on XP, for example.

> 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. 

This I'll believe. But that just means it doesn't move things reactively. 
That doesn't mean it doesn't move things proactively.

> 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.

No, it doesn't defrag all free space. But it does defrag some free space. 
There are calculations done as to whether it's worthwhile to move the file 
that's already defragmented.

> The stupid thing about this is.. assuming the files are mostly stable, 
> and won't change, 

Yep. Bad assumption, of course. But as I said earlier, the problem is with 
guessing the future.

> 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.

So write something that tells you what they are, and that moves it for you. 
You have the APIs. :-)

Seriously, there should be a piece of code that says "find the files with a 
gap more than 3x the size of the file in front and move it. :)

>>>> 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... 

Well, considering the OP had to hack the registry and turn off a couple of 
start-up tasks, I'm pretty sure.  You're talking about the 2G vs 3G limit. 
I'm talking about making 32-bit XP use 8G of RAM.

> 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. ;)

What partition of which drive is NTLDR on?  Plug in those numbers, and you 
win, if you're just using plain old SATA or IDE drives with no RAID or any 
weird stuff like that.   Heck, get the numbers out of your GRUB 
configuration for that matter.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message