Deletions Not Replicated When /Permit with /Automatic Is Used (241495)
The information in this article applies to:
- Microsoft Site Server 3.0
This article was previously published under Q241495 SYMPTOMS
When you use the Content Replication System (CRS), if a project is marked to "Replicate Directory ACLs only and Apply To Files" and a source file is deleted, the file is not deleted from the destination.
When you use CRS, marking a project to "Replicate Directory ACLs only and Apply To Files" does not propagate delete actions to the end-point servers. For example, when this setting is enabled, you can add a file or change a file and it propagates to the end-point server, but if you delete a file, it is not propagated to the end-point server.
CAUSE
This configuration (CRSS startrep <project> /permit /automatic) translates into: replicate directories-only with their ACLs and apply the ACLs to the files, keep running and replicate any changes to the project directory.
When the replication starts, it replicate the directories-only and the ACLs that are on the directories at that time, and then applies the ACLs to any files that exist in the directories. When the replication has synched, any changes (file or directory) will be replicated. The problem is that ACL-only changes are not detected. When the automatic replication is started, the only way an ACL change is replicated is if the file was modified (for example, the file has been touched).
The /permit and /automatic flags are not compatible. These two setting should not be used together.
WORKAROUND
To work around this problem, configure scheduled deployments instead of automatic, or use automatic replication and the /ACLs flag.
STATUSMicrosoft has confirmed that this is a problem in Site Server 3.0.
| Modification Type: | Major | Last Reviewed: | 10/22/2002 |
|---|
| Keywords: | kbbug KB241495 |
|---|
|