>If this is the case, do you think the situation (the claim of "no free space for defrag") would have been avoided by doing a defrag earlier?

Certainly. But I would guess (by the fact that a FORMAT was acceptable) that this was one of the luxury drives that is used for everything and anything except final versions of things.

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. Of course the drive needs monitoring to assure sufficient space is always available. At the price of drives today, and considering the 'scale' of the vast vast majority of VFP applications installed today, that isn't a serious problem. BUT... **IF** that problem state is reached then the most common solution will result in the contiguousization of each table on the new drive anyway.

cheers

>
>>SNIP>
>>>Also, NTFS reacts very badly to fragmentation. Had a big performance problem today with some tables that were copied en block but ended up in the cracks between a million fragments created by TurboDB. Raw file reads from that drive were slower than reads from a 10 MBit network, and the defragger wailed that there was no free space that it could use (0%) even though it reported 53% free space on that drive. Defragged by reformatting and afterwards performance was back to normal levels. *g*
>>
>>Defragger's 'complaint' sounds like it could well have been legitimate (more appropriately, I suppose, 'semi-legitimate)... If there wasn't a sufficiently large area of *contiguous* free space to let it use as an initial starting point then it gave up. A more appropriate response would have been to analyze further and **make itself** the contiguous free space, but it appears it doesn't do that. I wonder if the more expensive (than free) utilities for defrag do any better. One would hope so!
>>
>>That is likely the same reason that your 'en block' copy ended up fragmented all over in the first place.
>>
>>I guess your drastic 'defrag' was followed by lots of copying, and in such a case virtually every file copied should have ended up occupying contiguous space and your 53% free should now be all in 1 clump.
>>
>>cheers