Sync/mirror operation order

[DanSwitzer2]

Is there a way to set the precedence for the copy/delete? I really need the deletes to happen *after* the files are copied in my mirror operation.

The problem I'm running into is since files on the right are deleted *first*, there's a period of time when files on my server may break. If it copied the files over first and then deleted the files from the right, nothing would ever break.

Is there a way to set the copy/delete order in a sync operation?

[Chris]

It isn't possible to set the order that mirror does copies or deletes.

You could try using a BC script to copy the files, this way it would control the order of the deletes. Here's an example script:

load c:\source c:\target
sync update:lt->rt
select rt.orphan.files
delete rt

To run the script, use the command line "bcompare @script.txt".

This will sync newer and updated files from left to right, then delete files that only exist on the right side.

[DanSwitzer2]

It would seem to make sense to me to do deletes after the copies (or at least potentially make it an option.) Since "deletes" are orphaned files, why not delete those last?

(FYI - In my case their actually only orphaned after all the copies--since I have some JS files that have timestamps in them. I have an ANT script that concats a bunch of individual files. It builds the file w/a timestamp embedded as a revision stamp. This allows proxies to cache the files, but forces everyone to grab the new version of the files. When these files are deleted *first*, there's a brief period when the page might not work--because the old files get deleted before the new files and references to them get copied.)

[Michael Kujawa]

No batch of file operations is going to be atomic, so no order is really safe.

It seems to me like you need your deletes to happen much later than the copies. Once someone has fetched the referring files, there's a period of time where they need the old files. You probably need to wait at least the cache interval before deleting orphaned files. Ideally, you'd probably set up an entire new copy, then update the top-level entry points, then a day or two later delete the old copy. That way, the user is operating on a completely consistent version of the site no matter what order the operations happen in. The different path to the new copy takes care of caching issues, too.