In effect, the copy parameter is designed to be used in a sort of file server/local copy type situation. That is, each Citect machine has it's RUN= set to a local path, like c:\citect\user\example. It then has some other path in COPY=, like f:\citect\user\example. Then, when it starts, Citect considers these two directories and checks the file time/date on each file it loads as it loads them. If it finds that a file on the server (as defined in COPY=) is newer than the local version, it makes a copy from the server to update itself. That new file is then loaded. So as you can see, this update is performed strictly on files as Citect needs them and not on any other basis.

You can run Citect from one file server and have it's copy parameter set to some other server (ie no local copy of the project). So you can use this parameter to have Citect update one location from another. However, bear in mind that this is not a substitute for directory replication. Citect does not monitor the directory for changes as such, it merely notes time/date properties when it loads any particular file. If the work station does not need any file, it will not update one directory from another. Once Citect is up and running, only graphics page files fall into this category, because all other rdb's are loaded at startup only. This functionality is only available during Citect runtime. A little consideration will quickly reveal that it is still possible to have various machines scattered around a plant all running different versions because of this feature.

You should always specify a UNC path for the [CtEdit]Copy parameter, as specifying a mapped drive may have unexpected results.