Directory Deletions Under Replicator Service

MORE INFORMATION

The following examples demonstrate a typical directory export path.

Example 1

WINNT\SYSTEM32\REPL\EXPORT
                       |___ SCRIPTS
                               |___ script_files
                               |
                               |___ SUBDIRECTORY
                                       |____ more_files
				

Any files or directories put under the SCRIPTS subdirectory will be replicated, including deletions of files and subdirectories, provided the Entire Subtree box is selected under Manage Export Directories while you set up replication.

Example 2

When you add subdirectories under the EXPORT directory it is important to understand that if, in the future, you want to have the Replicator service delete unwanted trees, you need to add another subdirectory layer underneath as follows:

WINNT\SYSTEM32\REPL\EXPORT
                       |___ SCRIPTS
                       |       |___ script_files
                       |       |
                       |       |___ SUBDIRECTORY
                       |               |____ more_files
                       |___ OTHERTREE
                               |______ SUBDIR#1
                               |          |____ more_files
                               |___ SUBDIR#2
                                       |_____more_files
				

In Example 2, deleting OTHERTREE on the EXPORT SERVER will not cause the import server to delete OTHERTREE and its subdirectories. Only if SUBDIR#1 and SUBDIR#2 are deleted on the EXPORT SERVER will the deletions take effect on the IMPORT SERVER. This is by design because if a lock is put on an EXPORT subdirectory by an administrator or if the Wait Until Stabilized option is selected and recent changes to any of the exported files have taken place, then this TREE becomes invisible to the IMPORT SERVERS. Because of this, there is no way for the Replicator service to tell if the directory was deleted or if it's being hidden from view because of locks or because it is waiting for the stabilization timer to expire. Not deleting this tree structure on the IMPORT SERVER (if it is not found on the EXPORT SERVER) prevents having to re-export the entire tree once it becomes visible again.

If you do delete OTHERTREE on the EXPORT SERVER and you were expecting the Replicator service to delete its counterpart on the Import server, you should see NO_MASTER or NO_SYNC status, depending on how much time since the directory was last replicated. Again, this deletion will never take place by design.