>>>My take on defragmentation (or other ways to make files contiguous on a drive) is that it is not a good thing to do on a drive/partition that houses production VFP tables and their associated files.
>>
>>Yes, I remember you commenting on this topic. But in this case, it may well be that excessive fragmentation caused the slowdown. Fragmentation which, in this case, probably mixed up VFP data with other data.
>>
>>Your suggestion of not defragmenting makes sense - keep related data together, even if it belongs to different files - but that assumes it is not too mixed-up with data from unrelated tables!
>
>I agree very much that the POOR performance described in the defrag message was undoubtedly caused by most excessive fragmentation. That's what happens when you have the luxury of throw anything on it drive.
>A production situation would be significantly different all around.
>
>And, clearly, the defragger ought to be endowed with the logic to use the distributed fragmentation to build a contiguous space sufficient to then let it do the job it needs to do. At least when the free space percentage is better than, say 5% of the drive.

Clearly. If this is what it seems, it indicates a serious limitation in the defragmenter.

I have seen a similar situation only once in Ancient Times, with Stacker. The hard disk was almost full, with 130 KB or so free. Apparently, none of this space was big enough to accomodate a single complete cluster, and the defragmenter needed at least one free cluster. Stacker used variable-sized clusters (1-16 sectors, of 512 bytes each). The standard cluster size was 16 sectors; smaller cluster sizes could be the result of an effective compression, or simply of very small files or file fragments.

This problem was apparent resolved in Stacker version 4, which allowed clusters to be split up.

Perhaps the situation is somehow similar in the case under consideration.