>Ok, I'll show some longstanding ignorance on this one. i was under the impression that DBFs that were open could not be correctly copied (something to do with caching and the end of file marker), hence, Foxpro data could not be backed up while in use.
>
>I take it from your and Chaim's messages that this isn't true, but aren't there problems with stuff that hasn't been written from the cache?
>

If you're working with DBFs making backups from within a VFP app, what's wrong with something like:

nFiles = ADIR(aDBFs,'*.DBF')
cMyBackupDir = 'F:\Backup\'
cOldErrorHandler = ON('Error')
SELECT 0
lUsed = .F.
FOR i = 1 TO nFiles
   lUsed = .T.
   ON ERROR lUsed = .F.
   USE (aDBFs[i,1]) AGAIN SHARED ALIAS (SYS(2015))
   ON ERROR &cOldErrorHandler
   IF lUsed
      DO WHILE NOT FLOCK()
         *  Getting FLOCK() means that no one holds pending record or file locks
         *  yes, someone might have optimistic buffers, but not committed now
         *  and the current state of the table is stable for the duration of
         *  you holding FLOCK() on it.
      ENDDO
      COPY TO (cMyBackupDir + aDBFs[i,1]) WITH PRODUCTION
      UNLOCK
   ELSE
      *  couldn't open - bad file, some has it exclusive, etc.
   ENDIF
   USE
ENDFOR

Something like this takes care of managing all the related files, and could be used to do useful things like strip all the DELETED() records. Note this code has no error handling built in and does nothing to protect you from doing something really dumb, but it's not riddled with intentional errors that will result in your eventual need to commit suicide. It's not intended to be used as is for your complete backup solution. Objects in the mirror may be larger than they appear. This code is not inteded for use with delicate fabrics or to be served at room temperature. Lather, rinse, repeat...

You can also look at the code I posted for SHFileOperation() in the API section a couple days ago.