I'm still not sanguine that anyone will recognize a pressing need for a fragmenting utility, much less actually implement one.

First off, let's take a view from 10km. The folks who might be interested in fragmenting are those who are disk-bound. I think we have to assume these folks will have already invested in tons of RAM for OS disk cache, RAID arrays of high-speed disks, etc. They may have invested in high-performance servers and/or disk subsystems (locally attached or NAS/SAN) that are not even NTFS based (as trivial examples, think Novell or Linux/SaMBa). Both read and write caching will be enabled at the OS level.

One serious question is, are such people even going to be using VFP to store their data? Only if VFP is the fastest available solution for their needs. In many cases - I would guess most - the answer will be no, so your market is the subset of dedicated VFP users who are disk-bound.

Of the disk-bound VFP users, only some will benefit from purposeful fragmentation.

OK, now let's look at VFP. VFP works at the SMB level, making simple calls to SMB-compliant server(s) that may or may not be Microsoft-based (e.g. Novell and SaMBa). These SMB calls know nothing about the underlying devices - heads/cylinders/clusters/sectors, or even if they are disk devices (e.g. optical jukeboxes, RAM disks, etc.). Given the possible implementations of SMB compliant servers it is not possible for a client application to specify the geometry of data storage within them.

Since SMB isn't geometry-aware, now we're looking to modify the operation of specific SMB servers. There are two options here:

- Get the OS to treat VFP-specific files differently from others
- Leave the OS alone; instead, use a DiskFrag product to periodically "groom" VFP files to fragment them optimally.

Option 1 ain't gonna happen. To use MS as an example, there's no way MS would let the VFP hair at the tip of the tail wag the enterprise-fundamental NTFS dog. To those guys simple=good, complex=bad, and your plan is not simple. They would tell you to write a daemon to manage a monolithic file, as I outlined in an earlier message.

So, we've narrowed it down to Option 2. For DiskFrag to do its job it has to know a lot about the disk subsystem:

- Whether the device is a RAID array, striped, etc.
- Whether the volume, or individual files, are compressed (this is a biggie)
- Actual physical geometry of individual drive(s)
- Actual record sizes in .DBFs and .FPTs (at least)
- Multiply all of the above x # of distinct VFP apps on that volume/partition

This routine will be fiendishly complex. Its simplest task would be to purposely fragment contiguous files. Its most difficult challenge would be to consistently improve performance over that of a volume that has never been defragmented.

Finally, at the end of the day, how much performance have you gained? It's one thing to run synthetic benchmarks; quite another to test real applications at real user loads.