How does SYNC work? The SYNC command is as simple to use as the DOS XCOPY command, whether executed directly at the TMConsole (Shell) prompt or within a scheduled task. It not only replicates files / synchronizes data but also the names (DOS / Long / Macintosh / NFS), Ownership, Trustee Rights, DOS attributes, NetWare attributes, Inherited Rights Mask (IRM), and originating Name Space for both directories and files. Note: Ownership and Trustee Rights can only be replicated / synchronized within the same NDS Tree. However, SYNC will replicate / synchronize all other NetWare File System aspects for directories and files across NDS Trees. A source specification, a destination specification, and the appropriate options are required (no default options are assumed). The source specification can be a file, a file pattern, a directory, or a volume. The only requirement is that it MUST reside on the local Server and MUST be the first specification. The destination can be a directory within the same volume, a directory on a different Volume on the same (Local) Server, or a Volume and directory combination residing on a different Server, even across NDS trees. The format of the SYNC command is as follows: SYNC [[vol:]path\]spec [server/]vol:path [opts] [<sync.exc] [>sync.log | >>sync.log] The following options are supported by SYNC for data synchronization / file replication processing: /A Add source entries that do not exist on destination /B Block (delta change) updates (default = enabled, use /-B to disable) /C Compressed transfers (default = intelligent mode [i.e., not /C or /-C], /-C = never & /C = always) /D Delete entries that exist on the destination but not on source /E Exclusive source access mode (default, /-E = non-Exclusive, shared RO access) /F File data processing only (skip attribute only updates) /H Hidden / System entries are processed /I Ignore non-critical errors (default = Abort on any error) /J Jumble (encrypt) data during file transfer /K Keep subdirs (use with /D to exclude subdir deletion) /L Log command line (more info) /M Modified source entries copied to destination /O Ownership transferred (default - use /-O to disable) /Q Query mode (simulated processing - no dirs/files added/deleted/update) /R Replace (re-copy/update) destination entries with matching source entry /S Subdirectory recursion /T Trustee Rights transferred (default - use /-T to disable) /U Update source entry with newer destination entry /V Verify destination (replace if different from source) /W Warnings only (only log warnings & errors, not all activity) /X Exclude non-DOS Name processing (use DOS name only) /+IP[=x] IP preferred (if supported) with optional packet size of # (do not include brackets) /+NCP[=x] NCPE override (IP support ignored) with optional packet size of # (do not include brackets) /# Provides processing summary statistics >sync.log Redirected Server Console output (overwrite sync.log) >>sync.log Redirected Server Console output (append to sync.log) <sync.exc Redirected exclusion list input (source dirs/files to exclude)       Notes: There are no default processing options. If no processing options are specified, processing does not occur. Unless /Q is specified, any entries matching the specified option criteria will be processed with the following exceptions: NetWare Server or Volume specific system files, such as SYS:_SWAP_.MEM, SYS:VOLDATA.TDF, SYS:VOL$LOG.ERR, SYS:BACKOUT.TTS, and other common system files, are automatically excluded from SYNC processing. The source and destination directory specifications must already exist. The source directory must be on the local Server and can be relative to the Current Working Directory (CWD). Wild cards are supported in the source specification. No file specification is required or supported for the destination. The Block update option (/B) is designed to reduce LAN/WAN exchanges when updating large files that are prone to having data appended (i.e., log files, history files, transaction files, etc.). Using pre-read logic and CRC checks, it will compare existing file data to that which is being copied and determine if there are blocks of data which are identical and need not be transferred. The algorithm can significantly improve performance when updating certain files across a slow WAN. The Block update logic is enabled by default and can be disabled using the /-B option. Compression logic is designed to reduce LAN/WAN data transfers by default, with the options to control its usage: Default: If no option is specified on the command line, each file is initially compared against known file header patterns. Files which are recognized as already being compressed (i.e., NetWare compressed, .ZIP, .PDF, etc.) are transferred raw (or `as is'). An internal, performance optimized compression algorithm is used for the first few blocks of an uncompressed file and only continued if it yields sufficient compression gains to overcome the minimal overhead required to compress/decompress (i.e., a minimum of 8% required). /C Compress all data transfers. While even compressed files can typically be compressed further, the overhead required may not justify the savings. Only recommended when the Servers on each end are high performance (P-4 or better) and the link between them is exceptionally slow (under 512 Kbit). /-C Compression is disabled and all files are transferred raw (or `as is'). Recommended for slower Servers (P-3 or less) with high performance links (100 Mbit or better). The Exclusive source file access required option (/E) is enabled by default. When enabled, this option requires that SYNC be able to gain exclusive access to the source file before it can copy the contents otherwise the file is tagged as being and is not processed. This is the safest, most secure method of insuring data integrity. Disabling this default method of operation via the /-E option allows SYNC to access source files using a shared Read Only method which provides access to many files normally bypassed as being . However, caution should be exercised when using this option during heavy periods of user activity with files that are frequently modified as a file being copied by SYNC could possibly be updated by another process or user during the operation, potentially compromising the destination file contents. It is best utilized only during off hours when the chances are less likely that any files accessed in this shared manner might be modified while being processed. (Note: NetWare Compressed files have to be accessed in exclusive mode to maintain compression.) Name Space support is provided for DOS, Windows 95/98/NT/2000 (LONG/OS2), Macintosh (MAC), and Unix (NFS) entries under the NetWare File System. The /O (Ownership sync) and /T (Trustee Rights sync) options are enabled by default (i.e., do not need to be specified). The /-O and /-T options (to disable sync of Ownership and Trustee Rights) are most useful when synchronizing data or replicating files across NDS trees (since common Objects/Users would not exist for the Ownership and Trustee Rights synchronization). Unless the /Q (Query) option is specified, any entries matching the criteria will be processed. The /Q (Query) option can be used to determine if any processing would be performed based upon the source, destination, and options specified. When the Query option is specified, no directories or files are processed, no data transfer actually occurs. The specification and options are only used to determine and display the data synchronization / file replication requirements. If the /# option is also specified, an estimate of the amount of data needing to be transferred will be included. IP (UDP) is automatically checked and used for transferring data between properly configured and connected NetWare v5.0 (and later) Servers. Once it is determined that IP (UDP) is supported by both the source (Local Host) and destination (Remote Server), each are queried as to the Largest UDP Packet Size allowed (SET Largest UDP Packet Size). Starting with the smaller of the two values, a quick communications test is performed between the Servers which reduces the packet size in steps after each failure until a successful exchange occurs or the packet size drops below 1 KB, at which point the default NCP Extensions (NCPE) will be used. To specify a UDP packet size, use the following command line option: /+IP=?    ? = 1 - 32 (max packet size in KBytes) or 1024 - 32768 (max packet size in Bytes) The UDP packet size may need to be further reduced from the size determined during testing due to a slow WAN or congested link (see <Comm> / <Cksum> errors). To force the use of the NCPE guaranteed delivery protocol, use the following command line option: /+NCP=?     ? = 1 - 32 (max packet size in KBytes) or 1024 - 32768 (max packet size in Bytes) With NCP, the default packet size of 32768 should not need to be reduced unless <Comm> or <Cksum> errors are encountered. To check if IP (UDP) support is enabled on a Server, issue the following command at the TMConsole (Shell) prompt:         TMSERVER IP The Server's IP address and the port TaskMaster is listening on, as well as the MTU or largest UDP packet size supported by the Server, should be displayed. If the message Not Supported appears, TaskMaster was unable to establish IP (UDP) support on the Server. (Note: Such problems are most likely due to a port conflict.) Using input redirection (<sync.exc), specific files, file patterns, and directories can be excluded from SYNC processing. The exclusion list must be an ASCII text file containing one specification per line which matches the source file(s) to be excluded from the SYNC process. Wild cards are supported in the exclusion specification. The following criteria or rules apply: - Exclusion entries are specific to the source. Destination entries cannot be excluded. - NetWare Server or Volume specific system files, such as SYS:_SWAP_.MEM, SYS:VOLDATA.TDF, SYS:VOL$LOG.ERR, SYS:BACKOUT.TTS, and other common system files, are automatically excluded. - A generic file pattern (*.JPG) excludes any files in the base source directory which match the pattern. If the /S option is appended to the file pattern (i.e., *.JPG /S), any files matching the file pattern which reside in the subdirectory tree beneath the source are also excluded. - A path specific file or file pattern (e.g., SYS:SYSTEM\DS.NLM or SYS:SYSTEM\DS*.NLM) excludes any files in the specified directory which match (i.e., both examples will exclude the SYS:SYSTEM\DS.NLM file). If the /S option is appended to the specification (i.e., SYS:SYSTEM\DS.NLM /S), any files matching the file pattern which reside in the subdirectory tree beneath the specified path (SYS:SYSTEM) are also excluded. - A subdirectory specification without wild cards or file pattern (e.g., VOL:PATH) will exclude all directories and files in the specified subdirectory, including any which reside beneath the specification. It is more efficient to specify only the subdirectory instead of the subdirectory with a generic all file wild card (i.e., VOL:PATH is more efficient than VOL:PATH\*.*) as both provide the same exclusion results but the wild card specification requires additional processing. Input redirection of an exclusion file must follow all other options (except output redirection). A valid file specification must be provided (no wild cards). The file specification can be either fully qualified (vol:path) or relative to the Current Working Directory (CWD). Upon execution, SYNC builds a directory listing of the specified source and destination directories. Each directory listing entry consists of the DOS name, the Name Space name, and the directory information (attributes, size, date/time stamps, etc.). A complex set of logic and algorithms are then used to fully associated and properly compare the entries in the source and destination directory listings, even if the source entry has only a DOS name and the destination entry has both DOS and Name Space names (or vice versa). Note: Review How SYNC handles non-DOS entries? for more indepth information on Name Space support. The source and destination directory listings are then evaluated and processed depending upon the options specified and the following criteria: /A (Add) Criteria: Directory/File exists on the source but not the destination. Action: Source entry added to destination. /D (Delete) Criteria: Directory/File exists on the destination but not the source. Action: Destination entry is deleted. /M (Modified) Criteria: Last Modified date/time is more recent on the source. Action: Destination entry is updated using the source. /R (Replace) Criteria: File exists on both the source and destination. Action: Destination is replaced with the source. /U (Update) Criteria: Last Modified date/time is more recent on the destination. Action: Source is updated using the destination. /V (Verify) Criteria: Last Modified dates/times or sizes are not identical. Action: Destination is updated using the source. The order the options are specified does not affect processing or alleviate option conflicts. The options are processed in the following order: Delete (/D) Add (/A) Replace (/R) Verify (/V) Modified (/M) Update (/U) As a result, conditions for the Update (/U) option will never be met when the Replace (/R) or Verify (/V) options are used. Reason: The replace or verify criteria will match prior to reaching the update test. Unless the Update (/U) option is specified, the Verify (/V) option should be used in place of the Modified (/M) option. Reason: The verify test matches if the source and destination do not have identical Last Modified date/time and size entries. The modify test only checks if source has a later Last Modified date/time entry, size is not considered. Many virus programs will maintain previous attributes and time stamps when attaching themselves to a file, altering only the file's size. Once the specified source and destination directories have been synchronized, subdirectories are then processed recursively in the same fashion, (if the /S option has been specified). SYNC Examples: SYNC SYS:APP\*.* BACKUP:APP /A /A: Copy any source (SYS:APP) files which do not already exist on the destination (BACKUP:APP). SYNC SYS:APP\*.* BACKUP:APP /M /M: Copy any modified (newer) files from the source (SYS:APP) to the destination (BACKUP:APP). SYNC SYS:APP\*.* BACKUP:APP /R /R: Copy any common files from the source (SYS:APP) to the destination (BACKUP:APP). SYNC SYS:APP\*.* RSERVER/SYS:APP /A /D /M /S Process the local source (SYS:APP) and remote destination (RSERVER/SYS:APP) directories as follows: /A: Copy source files which do not exist on destination. /D: Delete any destination files not also on source. /M: Copy any modified (newer) files from source to destination. /S: Traverse the subdirectory trees recursively. SYNC SYS:APP\*.* FS2/SYS:APP /A /D /M /S <SYS:SYNC.EXC Same as above except that any files or directories matching the specifications in the exclusion list (SYS:SYNC.EXC input redirection file) are not processed. Note: Exclusion patterns / specifications are specific to the source. Destination entries ARE NOT compared against the exclusion list. Since the Delete option (/D) is specified in this example, files which exist on the destination but not the source will be deleted. To protect destination files which do not exist on the source from being deleted in a directory, exclude the source directory when the /D option is specified then individually process the source directory without the /D option. SYNC SYS:APP\*.* FS2/SYS:APP /A /D /M /S <SYS:SYNC.EXC >SYS:SYNC.LOG Same as above except with the Server Console output redirected to SYS:SYNC.LOG (overwritten). SYNC SYS:APP\*.* FS2/SYS:APP /A /D /M /S <SYS:SYNC.EXC >>SYS:SYNC.LOG Same as above except with the Server Console output redirected to SYS:SYNC.LOG (appended). Overview of the data displayed (or redirected to a log) during processing During processing, SYNC displays a running time / counter showing the elapsed time and the amount of processing performed. The first field is the elapsed time followed by the Exam fields (number of directories / files compared), the Proc fields (number of directories / files which were processed), the cummulative size of the files which were processed and the total number of errors encountered. Note: This information is current as of the v4.12 release. Previous releases may not include all of the same information or be formatted differently. Example: 00:10:00 - Exam: 1024 / 32768 - Proc: 256 / 4096 [256.1 MB - Errs: 0] Description: In ten minutes of processing, SYNC examined 1024 directories and 32768 files while performing processing against 256 of the 1024 directories and 4096 of the 32768 files. The cummulative data size for all the files processed totals 256.1 MB and no errors have been encountered to this point. The data field does not represent the amount of data that has actually been transferred. Depending upon the type of file being processed and the options specified, the actual amount of data communicated between the Servers could be much less due to Block (Delta Change) Updates and/or the dynamic real-time Compression available for data transfers. The amount of Communicated data and total Communications I/O, as well as the cummulative Data size for the files, is summarized at the end of the SYNC. SYNC will also display up to four fields of information about each entry that is processed (this information display can be disabled or redirected to a log file - refer to the Output Redirection topic). The four fields of information are presented in the following format:       Field Contents Description Type [DIR]     File     Action (add) Added: To destination (/A)   (del) Deleted: From destination (/D)   (ent) Entry: Updated (/M, /U, or /V)   (exc) Excluded: Source entry skipped   (mod) Modified: Destination updated (/M)   (nam) Name: DOS/Long conflict   (rep) Replace: Destination replaced (/R)   (upd) Update: Source updated (/U)   (ver) Verify: Destination updated (/V)     Action Note(s): (ent) processing only occurs when the /M, /U, or /V options are specified and all other comparison criteria (i.e., date/time and size) do not require an action but there is a discrepancy in the NetWare attributes (access control attributes, Extended Attributes, Ownership, or Trustee Rights) between the source and destination. With the (ent) action, only the directory entry information is updated (i.e., attributes, date/time stamps, Ownership, and Trustee Rights, if /-T was not specified), no data is exchanged. Name [server/]vol:path\name.ext [server/] = Destination: (del) & (upd)   /   Source: All other Actions     Note: [server/] only appears in Server-to-Server SYNC operations   Result Result Notes: [SYNC] is output following entry (name) if no errors occurred with the directory / file creation and / or data transfer. If a critical error occurs during processing, a description of the error will be enclosed within <> signs. If a non-critical error occurs during processing, a description of the error will be enclosed within {} signs. Non-critical errors include attribute, name space, ownership or trustee rights synchronization with the source (i.e., entry is created / updated but directory information is not fully synchronized).     [SYNC] Synchronized (No Errors)     <Info> Unable to retrieve entry information   <Delete> Error deleting destination   <Create> Error creating destination   <Open> Error opening source / destination   <InUse: Src | Dst> Error opening source | destination (file open / in use)   <Read> Error reading source   <Write> Error writing destination   <Cksum> Checksum error (corrupted data)   <Comm> Communications error (failed comm)   <H | Sys> Hidden/System entry (requires /H)   <NS: ns | #> Unsupported Name Space (NS name or invalid NS #)   <Err: #> NetWare internal error code     <... entry count exceeds limit (32768)> Entry count (dirs / files) exceeds limit for a single directory   <Destination DIR Info | List Error> Unable to retrieve Destination Directory Information / Listing     {Attr} Cannot set attributes for destination   {Owner} Cannot set owner for destination   {Trustee} Cannot set trustee for destination     Error Notes: <Info> (Entry Information) errors indicate SYNC was unable to retrieve basic directory entry details for the named file. These errors typically occur when a file is deleted between the time the directory listing was collected and SYNC attempts to process the file (not uncommon with temporary files in active directories). <Cksum> (Checksum) errors indicate a communications conflict during the exchange of data with a Remote Server. Each block of data transmitted between Servers is includes a data checksum to insure data integrity at the destination. <Cksum> errors indicate the data received by the Remote Server has been corrupt on the initial attempt and several re-tries. <Cksum> errors are considered critical errors which cannot be overriden by the /I (Ignore Non-Critical errors) option. (For more information on resolving <Cksum> errors, review the <Comm> errors section which follows.) <Comm> (Communications) errors indicate a communications conflict during the exchange of data with a Remote Server. <Comm> errors indicate that communications has failed on the initial attempt and several re-tries between the two Servers. <Comm> errors are considered critical errors which cannot be overriden by the /I (Ignore Non-Critical errors) option. Data transfers between Servers will almost always be sent in blocks that are larger than the Maximum Transport Unit (MTU) for the protocol in use, especially if the link is a WAN. In such cases, the protocol driver will disassemble the larger packet containing the block of data into smaller packets of MTU size (or less) which it then transmits to the Remote Server where they are re-assembled back into the original larger packet containing the block of data (fragmentation). SYNC incorporates logic that attempts to test the communications link in an effort to determine a reliable packet size, as well as logic to re-transmit the data, up to a defined number of times appropriate for the link, whenever an error occurs. However, changing WAN conditions &/or load factors during SYNC operations may result in <Comm> &/or <Cksum> errors being encountered. Possible Communications errors include: 0x02 (Listen Error) The listening socket on the source Server encountered an unrecoverable error. 0x0D (Socket Error) The sending socket on the source Server encountered an unrecoverable error. 0x10 (Timeout Error) No reply was received within the allow time out period. This could occur during extremely heavy NSS I/O when NSS gets into conditions that delay its response or if the Server becomes so overloaded with queued requests that it fails to respond within the allow time. It is often followed by the 0xA6 (Server Busy) error as the request is repeated. 0xCD (Out Of Range) The packet size is larger than the protocol supports. Should not occur as the first step in establishing a link between Servers is to determine the largest common UDP packet size supported between the Servers. Even if that value is changed after the start of a SYNC, logic exists to automatically detect the error and attempt to reduce the packet size until communications can resume. 0xA6 (Server Busy) The destination Server is busy servicing a another request. Can be caused if NSS encounters a spin lock or similar condition which requires an unusually extended period of time to respond. 0xD5 (Inspect Error) The contents of the reply packet are corrupt (in addition to standard protocol checks, SYNC also performs internal checks on packet size and a checksum of the contents). 0xF9 (No Connection Slots) The destination Server connection queue is full. Should only occur if more than 64 concurrent remote SYNC tasks are actively communicating with the same Server. 0xFA (No Known Route To Destination) The route to the destination Server has changed and routing tables can no longer provide the necessary route information. This is a rare network transport issue. 0xFD (Invalid Packet Length) The packet was somehow corrupted during transmission causing the contents to be of a different size than the packet header specifies. Can be caused by UDP fragmentation errors. In the case of most 0x10 (Timeout Error) or 0xA6 (Server Busy) errors, the bottleneck is going to tend to be Disk I/O and NSS in which case maximizing memory on the Server and tuning the Server (memory and NSS) can improve the situation. Another option is to reduce the packet size during the transfers (refer to /+IP=#### and /+NCP=#### options described below). However, if 0xA6 errors persist, the problem is probably not with communications as much as NSS delays. In such cases, there are two possible settings which can be adjusted to extend the time out setting. The default setting is shown along with the range (upper/lower limits) supported. TMSET Request Retries = 5 (Limits: 1 to 10) Maximum retries per Server-to-Server exchange TMSET Request Timeout = 15 (Limits: 1 to 30) Maximum time out (secs) per Server-to-Server exchange If used, the TMSET command either be executed at the TMConsole (Shell) prompt prior to executing the SYNC script or included within the script, prior to the SYNC command. Note: Once set, the parameters remain in effect for all TaskMaster processing until changed or the NLM is reloaded. In some cases, it may be necessary to manually reduce the size of the data block being transmitted in order to reduce the number of associated packets for each data block and ultimately reducing the probability of corrupted or lost packets causing errors. When IP (UDP) is supported for communications between the Servers, it is possible to specify the UDP packet size on the command line as follows: /+IP=?    ? = 1 - 32 (max packet size in KBytes) or 1024 - 32768 (max packet size in Bytes) If <Comm> &/or <Cksum> errors persist and cannot be resolved by adjusting the UDP packet size, it is possible to force the logic to use NCP Extensions (NCPE) which provides guaranteed delivery using the NCP Protocol, although much slower than possible via IP (UDP). To force the logic to use the NCPE delivery method, use the following command line option: /+NCP=?     ? = 1 - 32 (max packet size in KBytes) or 1024 - 32768 (max packet size in Bytes) With NCP, the default packet size of 32768 should not need to be reduced unless <Comm> or <Cksum> errors are encountered. <Destination entry count exceeds limit (32768)> | <Source entry count exceeds limit (32768)> SYNC has a default limit of 32768 entries (directories / files) within a single directory (i.e., one subdirectory, not a volume or subdirectory tree). As of v4.15, the limit can be increased using the /+ENT=##### option on the SYNC command line (where ##### is the new maximum limit for entries within a single subdirectory). Since incrementing the entry count limit also increases the amount of memory allocated for each active SYNC operation, it is advised to determine the absolute maximum value needed then pad that value by 512 and round up that value to the nearest multiple of 1024 rather than just arbitrarily increase the value to a much larger count. Example:   SYNC srcpath destpath opts /+ENT=33792 (increases the maximum number of entries supported for a single subdirectory from the default 32768 to the increased maximum of 33792). <Destination DIR Info> | <Destination DIR List> SYNC could not retrieve the entry information / listing for the specified subdirectory on the destination Server. SYNC walks the local and remote subdirectory trees, collecting and comparing entry listings and information for each subdirectory in the tree to determine which directories or files need to be processed. This error only tends to appear in one of three cases: The directory structure is fairly branched and populated but few files need to be processed so SYNC ends up walking the tree faster than the Directory Cache Buffers can build &/or replenish in which case increasing the Minimum and Maximum Directory Cache Buffers setting can often help. This situation can also happen when a Server has not been operating very long so the Directory Entry Tables are not fully populated. The destination Server subdirectory tree structure tends to have a lot of files in each subdirectory and is low on short term allocatable memory limiting the ability to allocate temporary memory to store the directory information / listings until it can be transmitted (more Server RAM is advised). The destination Server has insufficient Packet Receive Buffers to maintain the rate of exchange for the subdirectory listings / information in which case increasing the Minimum and Maximum Packet Receive Buffers setting can often help. Note: Increasing the Minimum / Maximum Directory Cache Buffers or the Minimum / Maximum Packet Receive Buffers settings may require the addition of RAM in the Server to maintain stable performance and operation. Optimized SET Parameters for Server-to-Server operations {Attr} errors are non-critical and uncommon. This error can be the result of a workstation or process (possibly an Anti-Virus NLM) opening the file (restricting SYNC's ability to make any changes to the file) between the time that SYNC completes the data transfer and attempts to set the destination entry information to match the source. {Owner} errors are non-critical and uncommon. They most often occur during synchronization across NDS trees, or if the NDS replica on the destination Server is not current. For these scenarios, specify the /-O option (Owner not updated) to avoid these errors. This error can be the result of a workstation or process (possibly an Anti-Virus NLM) opening the file (restricting SYNC's ability to make any changes to the file) between the time that SYNC completes the data transfer and attempts to set the destination entry information to match the source. {Trustee} errors are non-critical and uncommon. They most often occur during synchronization across NDS trees, or if the NDS replica on the destination Server is not current. For these scenarios, specify the /-O option (Owner not updated) to avoid these errors. This error can be the result of a workstation or process (possibly an Anti-Virus NLM) opening the file (restricting SYNC's ability to make any changes to the file) between the time that SYNC completes the data transfer and attempts to set the destination entry information to match the source.   {DOS} DOS name conflict (Source & Destination DOS names mismatch)   {DOS / ns} DOS & ns name conflicts (Source & Destination names mismatch for DOS & Long | Mac | NFS)     Name Space Conflict Notes: {DOS} name conflicts are common, especially in mixed NetWare v4 / v5 / v6 environments and on NetWare v4 Servers which have not had the MIXMODFX patch applied. {DOS / ns} name conflicts are infrequent and indicate that there is a case discrepancy between the source and destination non-DOS names which SYNC could not resolve at this time. In most cases, SYNC can resolve such name conflicts. Name conflicts can be checked by executing a TaskMaster DIR against both the source and destination entries, the identified name space entries (i.e., DOS | DOS / ns) will not be identical. SYNC Output Examples: The following are examples of output from SYNC processing (either displayed on the screen or redirected to a file): File  (add) SERVER/VOL:PATH\NAME.EXT [SYNC] SYNC determined a File needed to be added (add) to the destination. The file to be added was SERVER/VOL:PATH\NAME.EXT and was successfully added ([SYNC]). [DIR] (del) SERVER/VOL:PATH\NAME.EXT [SYNC] SYNC determined a directory [DIR] needed to be deleted (del) from the destination. The directory to be deleted was SERVER/VOL:PATH\NAME.EXT and was successfully deleted ([SYNC]). File  (ent) SERVER/VOL:PATH\NAME.EXT [SYNC] SYNC determined a File had NetWare attribute or Inherited Rights Mask (IRM) discrepancies (ent) between the source and the destination. The directory listing information from SERVER/VOL:PATH\NAME.EXT was successfully replicated ([SYNC]). Note: No file data transferred, only directory entry data. File  (mod) SERVER/VOL:PATH\NAME.EXT <InUse> SYNC determined a File met the /M (Modified) criteria (mod). The source file to be copied was SERVER/VOL:PATH\NAME.EXT but it could not be opened as it was already open by a User (<InUse>). File  (nam) SERVER/VOL:PATH\NAME.EXT [SYNC] SYNC determined a File had a name mismatch (nam) between the source and destination directory listings. The source file involved was SERVER/VOL:PATH\NAME.EXT. The name conflict was successfully resolved ([SYNC]). File  (nam) SERVER/VOL:PATH\NAME.EXT {DOS} SYNC determined a File had a name mismatch (nam) between the source and destination directory listings. The source file involved was SERVER/VOL:PATH\NAME.EXT. The {DOS} name conflict could not be resolved (i.e., [SYNC] does not appear). File  (ver) SERVER/VOL:PATH\NAME.EXT [SYNC] {DOS} SYNC determined a File had a verification mismatch (ver) between the source and destination. The source file involved was SERVER/VOL:PATH\NAME.EXT. The data was synchronized ([SYNC]). However, a {DOS} name conflict was detected and could not be resolved. Note: SERVER/ only appears during processing between Servers, not when the source and destination are both on the local Server. SYNC Summary Examples: The following information is recorded if the SYNC Output is redirected (or logged) to a file: SYNC v4.12 - Mode: IP (192.168.1.51 / MTU: 32768) SYNC v4.12 - Mode: NCPE SYNC v4.12 - Mode: Local The SYNC version and data transfer mode (IP with destination IP address and largest UDP packet size, NCP Extensions or Local). Time: 00:02:03 - Exam: 852 / 11728 - Proc: 5 / 22 Elapsed time, the number of directories / files examined (compared) and number of directories / files which required processing (created / updated). Comp: NW 0 / TM 14 / Raw 7 Number of files transferred in a NetWare compressed state, number of files transferred using TaskMaster real-time compression and number of files transferred raw (i.e., as is - too small to compress or already in a recognized compressed format). Note: TaskMaster real-time compression not used for Local SYNCs. Data: 107.10 MB - Comm: 16.87 MB (I/O: 22.86 MB - Req: 8688 / 0) The total amount of data associated with the files which were processed, the total amount of communications required to transfer the file data, the total amount of communications required for all of the processing (directory listing retrievals, dir/file creation, data transfer and entry information updating), the total number of information requests to the Remote Server and the total number of information requests retried due to comm errors. Note: Comm will usually be less than Data due to TaskMaster real-time compression and block (delta change) update logic. For Local SYNCs, only a Data value is recorded since no Comm occurs. Aborting a SYNC: The ABORT Console Command can be used to terminate any active SYNC processing. To terminate ALL active SYNC processing, enter the following at the TMConsole (Shell) prompt:     ABORT SYNC To terminate the SYNC processing associated with a specific task, enter the following at the TMConsole (Shell) prompt:     ABORT [taskname] Replace [taskname] with the DOS 8.3 file name of the active task. Multiple / Concurrent SYNCs: How to? Caveats? Checking if a specific task is already running? If the SYNC command is executed at the TMConsole (Shell) prompt, only a single SYNC operation may be launched at a time. The current release of TaskMaster limits manual execution of a SYNC process to one operation at a time to insure that the environment and stack used by the SYNC operation is protected. If multiple, concurrent SYNC operations are necessary, each SYNC operation will need to be incorporated into its own task script. By initiating the SYNC operation from within a task, each SYNC operation is assured its own environment and stack is protected from the other SYNCs. TaskMaster is capable is supporting up to 64 concurrent tasks (assuming sufficient Server resources exist to support so many operations). Therefore, it is possible to launch up to 64 concurrent SYNC operations at a time to push data out to more than one Server at a time. However, there are some caveats or limitations which must be respected: Concurrent SYNCs over a WAN - Case in point: During the 2000 Census, the U.S. Census Bureau used TaskMaster's SYNC command to collect and redistribute data between up to 500 Servers on a nightly basis. Their design utilized a tiered collection method with the main office collecting data from regional offices which had previously collected the data from regional offices. The distribution method was identical but in reverse with the main office distributing the data to the regional offices which then distributed the data to the local offices. All via TaskMaster and accomplished using the SYNC command in custom scripts. Caveats of multiple, concurrent SYNC operations: There are a couple of limitations which should be noted if multiple concurrent SYNC operations are planned. Multiple SYNC operations utilizing the same source directory structure may conflict if more than one SYNC process attempts to access the same source file simultaneously. While SYNC will normally access source files in a shared, read-only mode that will allow multiple SYNC operations to access the same file concurrently, NetWare Compressed files (files which have not been accessed within the SET defined period and the file system have compressed - as indicated by the Co status attribute) must be opened in an exclusive mode in order to be processed. Thus, it is possible that two SYNC operations might conflict should both attempt to access the same Compressed file concurrently. (Note: This conflict can usually be avoided by staging the SYNC tasks or operations at intervals and/or by arranging the SYNCs from the fastest remote Server connection to the slowest.) Multiple SYNC operations accessing the same destination directory structure may conflict if more than one SYNC process attempts to access the same destination file simultaneously, unless all of the source files are identical. (Note: Because of the streamed update of the data, it is possible that the data from the two different source files could be intermixed, yielding a file which does not match either file.) Concurrent SYNC Tips: Multiple, concurrent SYNCs will perform without conflict within the following guidelines: SYNC from multiple Slave or Remote Servers to separate volumes or directories on a single Master or Local Server SYNC from separate volumes or directories on a single Master or Local Server to multiple Slave or Remote Servers SYNC from the same directory structure on a single Master or Local Server to multiple Slave or Remote Servers if the starting time for the tasks are slightly staggered so that no two SYNCs should attempt to process the same file at the exact same time (Note: The only real conflict is with NetWare Compressed files which have to be accessed in an exclusive, non-shareable mode in order to maintain the compressed status. Files which are not NetWare compressed are accessed in a shared mode allowing multiple concurrent SYNCs to share the same source file for processing.) Checking if a specific SYNC task is already running? Logic can be added to the task used to execute the SYNC command to insure that the same task does not execute if already active, allowing a SYNC in process to complete before the next launch of the same SYNC task. Additional information and code examples on this topic can be found on the TaskMaster Tips page: TaskMaster Tips: Overlapping Tasks How SYNC handles non-DOS entries? There are caveats associated with Name Space support on any platform that supports more than one naming convention. These caveats are more complex on NetWare Servers due to the fact that the underlying file system is DOS based and treats non-DOS names as an alias for or extension to the DOS entry. Most of NetWare's support modules and the vast majority of utilities common to the NetWare marketplace either support DOS names only (ignoring the non-DOS name) or non-DOS names only (ignoring the DOS name). This approach further complicates the caveats, especially if the utilities are used to backup, copy, move, or update critical data files. For more information on the caveats associated with non-DOS Name Space support, review the following document (Adobe Acrobat .PDF format): Caveats for Non-DOS Name Space Support To download Adobe's free Acrobat Reader, visit: http://www.adobe.com TaskMaster, in general, and the SYNC command, specifically, have been carefully designed to respect both the DOS and non-DOS names, thus avoiding most of these caveats. However, in some cases, operator interaction may be required as logical assumptions are neither obvious nor risk free and, thus, are avoided. For more information on general Name Space support and specific issues affecting TaskMaster, review the Name Space Support topic in the TaskMaster FAQ. The SYNC command performs its processing duties by building directory listings of the source and destination directories then comparing the directory listings. Each directory listing entry consists of the DOS name, a hash of the non-DOS name (if created as other than a DOS entry), and the directory information (attributes, size, date/time stamps, etc.). The name data (DOS and/or non-DOS) is used to determine if matching entries exist in both the source and destination directories. By default, the logic searches for DOS name matches among those entries which have DOS names only (no non-DOS name associated with the entry); and then for matches among those entries which have non-DOS names (all entries with non-DOS names also have DOS names). Entries which have a non-DOS name in either the source or destination directory (but not in both), may not be processed as expected since a matching entry will not exist. Therefore, it is often prudent to expand the options beyond the obvious requirements in order to insure proper synchronization of the directories. To better understand how the entries are processed, the following explains the logic used for the options: /A (Add) Source entries with: Matching DOS names in the destination directory listing and no non-DOS name associations in either directory listing; Matching non-DOS names in the destination directory listing (even if the DOS names do not match); fail to match the /A (Add) criteria. All other entries in the source directory listing, including entries which have matching DOS names in the destination directory listing but a non-DOS name associated in only one of the directory listings (source or destination, not both), will match the /A (Add) criteria. If an unmatched source entry has a non-DOS name entry, the source non-DOS name is used. Once the entry has been created in the destination directory, SYNC will attempt to synchronize the DOS name for the destination entry with the DOS name for the source. The synchronization of the DOS names can fail if another entry is already using the DOS name. Since it is impossible for TaskMaster to verify with 100% certainty which entry should have the DOS name or the possible ramifications of removing the conflicting entry, no further resolution is attempted since the non-DOS names match and the entry was successfully created. If matching DOS name entries are found and the logic used for evaluating the options indicates the entry needs to be processed, the source DOS name is used. /D (Delete) Destination entries with: Matching DOS names in the source directory listing and no non-DOS name associations in either directory listing; Matching non-DOS names in the source directory listing (even if the DOS names do not match); fail to match the /D (Delete) criteria. All other entries in the destination directory listing, including entries which have matching DOS names in the source directory listing but a non-DOS name associated in only one of the directories (source or destination, not both), will match the /D (Delete) criteria. /M (Modify)   /R (Replace)   /U (Update)   /V (Verify) Entries with: Matching DOS names in both directory listings and no non-DOS name associations in either directory listing; Matching non-DOS names in both directory listings (even if the DOS names do not match); match the /M (Modify), /R (Replace), /U (Update), and /V (Verify) criteria. All other entries in the source and destination directory listings, including entries which have matching DOS names in both the source and destination directory listing but a non-DOS name associated in only one of the directories (source or destination, not both), will fail to match the /M (Modify), /R (Replace), /U (Update), and /V (Verify) criteria. If matching non-DOS name entries are found and the logic used for evaluating the options indicates the entry needs to be processed, the source non-DOS name is used. Once the entry has been successfully updated, SYNC will attempt to synchronize the DOS name for the destination entry with the DOS name for the source. The synchronization of the DOS names can fail if another entry is already using the DOS name. Since it is impossible for TaskMaster to verify with 100% certainty which entry should have the DOS name or the possible ramifications of removing the conflicting entry, no further resolution is attempted. However, a message is generated indicating that there is a DOS name conflict between the source and destination files. Since the non-DOS names matched and the entry was successfully updated, this conflict is not considered a critical error which could terminate processing. If matching DOS name entries are found and the logic used for evaluating the options indicates the entry needs to be processed, the source DOS name is used. Summary of Option Usage with non-DOS Names: To insure full synchronization of the directories, the /A (Add) and /D (Delete) options should also be used whenever the /M (Modify) or /V (Verify) options are specified. The addition of the /A and /D options should help cleanup any mismatches between the source and destination directories for any entries which have a non-DOS name in one directory and not in the other. There is no discernable overhead associated with the additions of the /A and /D options, except when entries must be added or deleted to properly synchronize the directory contents. DOS Name Processing Option: The /X (eXclude non-DOS name processing) can be specified to limit the processing to DOS names only and avoid such non-DOS name conflicts. However, this option should only be used in those cases where it is known for certain that no DOS name conflicts exist between corresponding files in the source and destination directories or when synchronizing between a volume with non-DOS support and one without non-DOS support. DOS / Non-DOS Name Space Name Conflicts: Occasionally, SYNC may generate the following notice after processing has completed:           *** # NS Name conflict(s) exist ***           *** Logged using {ns} tags *** Since SYNC was not able to provide completely synchronize the directory entries that were processed, including the DOS name, it provides the notice of such DOS / Non-DOS name conflicts. In such cases, one or more (the value shown in place of the #) entries had DOS and/or Non-DOS name conflicts between the source and the destination which SYNC was unable to resolve. Each entry with such a conflict have a {DOS}, {Long}, {Mac}, {NFS}, or {DOS / ns} (where ns = Long | Mac | NFS) }name conflict indicator tag following the Result tag ([SYNC] or <err_desc>). {DOS} name conflict indicator tag designates a discrepancy between the source and destination DOS names. Such conflicts are not unusual on NetWare v4 Servers which do not have the MIXMODFX patch applied or on Servers where the files were originally created with standard DOS/Win32 utilities, including Novell's NCOPY and others. Most such utilities are not designed to maintain proper DOS names. {ns} (where ns = Long | Mac | NFS) name conflict indicator tag designates a discrepancy between the source and destination non-DOS names. A case difference between the names (example: LongName vs. lONGnAME). Almost always corrected by SYNC. {DOS / ns} (where ns = Long | Mac | NFS) name conflict indicator tag designates a discrepancy between the source and destination DOS and non-DOS names. Very rare for both names to have conflicts. The notice is intended as an informational message indicating the potential for file name conflicts in the future. Since it is only a potential for problems and not any actual problem encountered by SYNC, the message is listed as being informational. Name conflicts are not unusual on platforms which support incompatible name conventions within a single file system. The file naming limitations for DOS and non-DOS names are obviously different. To support multiple Name Space conventions, the NetWare File System must not only recognize both names (DOS and non-DOS) but must convert the non-DOS name to a unique name which adheres to the DOS 8.3 format for primary access. The NetWare File System uses an arbitrary, order based, renaming convention to accomplish the task. This renaming convention is the source of the DOS name conflicts. {DOS} name conflicts are not unusual, especially when files are created using non-NetWare compatible utilities (i.e., Windows Explorer, DOS COPY/XCOPY, or other utilities not specifically supporting NetWare file system conventions). In most cases, such conflicts will go unnoticed. In some rare cases, DOS name conflicts can create problems. That is why SYNC both tries to correct them and generates an informational message about their existence. NetWare relies upon the DOS name space as the primary directory entry with the other name spaces, including non-DOS names, being merely links, aliases, or references to the primary DOS directory entry. Most NetWare NLMs and DOS/Windows 16 bit applications utilize DOS name space support while Novell Java and DOS/Windows 32-bit applications utilize Long name space support. The TaskMaster NLM with its Server Console extended command set utilizes both DOS and Non-DOS Name Space support. If the files which display such conflicts are accessed primarily by DOS/Windows 32-bit applications and NLMs (such as TaskMaster) which support both name spaces then these conflicts should not pose any problems. The fact that such name conflicts only become evident after using the SYNC command would further suggest that the likelihood of conflict is rare. Except for UNIX (NFS Name Space) applications, {Long} name discrepancies tend to be harmless. Under Windows and NetWare, the file names LongNameSpace.Text and longnamespace.text are considered identical because Long Name Space support in both Windows and NetWare is case insensitive. Only an Operating System which supports case sensitive file naming conventions (such as UNIX NFS) will have a conflict. Although not critical except under NFS, we flag all case mismatches in non-DOS Name Spaces with the {ns} tag (where ns = conflicting Name Space) and generate an informational message about their existence. Novell has one very interesting caveat in its non-DOS Name Space support. Under Novell, it is possible to have a non-DOS file (having both non-DOS and DOS names) and a different DOS file (DOS name only) share the same name. While rare, this can create serious conflicts since an attempt to open the file by the common name will result in the entry associated with the first occurrence of the name in the directory listing encountered being accessed, not necessarily the desire file. Fortunately, Novell is the only widely used platform on which this conflict exists AND the occurrence of such problems is rare. What is the difference between PUSH, PULL and PUSH/PULL? How does SYNC work? Definitions of Synchronization Designs: PUSH The Master (Source) directory structure is the Master template for synchronizing the Slave (Destination) directory structure. PULL The Slave (Destination) directory structure is the Master template for synchronizing the Master (Source) directory structure. PUSH/PULL Both directory structures are compared against an index or template allowing two way synchronization. TaskMaster's SYNC command was designed to use the PUSH concept which assumes a Master (Source) and one or more Slave (Destination) locations which need to be synchronized to the Master (Source). The PUSH design was chosen because it is the most common usage of synchronization and the easiest for the User to maintain. SYNC's design can automatically handle the distribution of new (/A) dirs/files and the updating (/M or /V) of files from the Master to the Slave(s), as well as the removal (/D) of any extraneous dirs/files placed on the Slave(s). To assist with those cases where PULL capabilities were desired, the /U option was added to allow a more recently modified Slave file to be updated to the Master. Thus, the /A /M /U combination can be used for limited PUSH/PULL operations. This design appears to accommodate 99% of the sites seeking synchronization products. However, it does not represent a true PUSH/PULL concept in that it does not add new dirs/files from the Slave(s) to the Master. Without an index or template to know which files are supposed to exist, it is impossible to know if a dir/file that exists in only one location is newly created or a remnant of a deletion from the other location. While other products may support an index or template design, such products are not as easy to use nor as dynamic as SYNC since the index or template must be updated each time a dir/file is added or deleted from either side. In a typical office environment, such a maintenance task can prove daunting and time consuming. As previously indicated, SYNC can be used in a limited PUSH/PULL manner through the use of the combined /A /M /U options (add new dirs/files, distribute newer Master data, and retrieve newer Slave data). Utilizing the capabilities within TaskMaster and task scripts, it is possible to take the PUSH/PULL concept a bit further: By first executing a SYNC /A /M on the Master (PUSHing new dirs/files and more recently modified files from the Master to the Slave) then reversing the procedure (i.e., remotely launching a task which performs the same command, PUSHing new dirs/files and more recently modified files from the Slave to the Master). There are two caveats to this method; First, it does not accommodate the deletion of dirs/files from only one location since they will just be re-added by the next SYNC process. Second, the task needs to be designed carefully such that the Master waits for the spawned (or remotely submitted) Slave task to complete (i.e., the Slave must notify the Master once finished) and the Master task checks that it is not already active during initiation to avoid overlapping SYNC tasks. To utilize SYNC in a try PUSH/PULL environment, the decision must be made either not to delete extraneous dirs/files or not allow dirs/files to be created on one of the two locations (i.e., any new dir/file must be either simultaneously added to both Servers or only created on one location which is also the only location where the /A option is specified). Obviously, the former is easier than the latter. However, the former requires periodic manual intervention to determine which dirs/files are extraneous (a periodic task which checks the Last Access Date for any dirs/files could be performed weekly - the granularity would have to be at least one day since the Last Access Date field does not maintain a time relationship). By contrast, the latter works quite well as long as dirs/files can only be added to one side and the /D (Delete) option is only specified in SYNC operations which use that side as the Master (Source). In summary, SYNC cannot perform a TRUE PUSH/PULL. However, between the options available in SYNC and the capabilities within TaskMaster and its scripting language, it can come very close with far less demands on the support staff than other concepts tend to require. The following is an example task script (.TSK) which could be used to simulate a PUSH/PULL synchronization as closely as possible with SYNC: Overview of example task (.TSK) files: SYNCA2B.TSK is the scheduled task which would be launched on the Source (Local Server: [LServer]). It will SYNC (PUSH) the directory structure on [LServer] to the Destination (Remote Server: [RServer]) then send a command to [RServer] to launch SYNCB2A.TSK to SYNC PULL - reverse PUSH) the directory structure from [RServer] to [LServer]. Both examples are overly simplified tasks but include logic to prevent multiple concurrent executions of the SYNC processing (i.e., to insure both the PUSH and PULL phases complete before another scheduled execution is allowed). SYNCA2B.TSK should reside on [LServer] and is the scheduled task. SYNCB2A.TSK should reside on [RServer] and is launched by SYNCA2B. Example Task Notes: The Delete (/D) option specifies that any directories or files which exist on the Destination but not on the Source should be deleted. Therefore, using the Delete option would not leave any new directories or files on the Destination to PUSH (reverse direction PULL) to the Source since any such extraneous entries would have been deleted. Thus, the Delete option should not be used for PUSH/PULL synchronization. The brackets ([]) surrounding the Server names are included for documentation purposes only. When replacing the Server names in these examples, exclude the brackets. VOL:PATH should be replaced with the appropriate NetWare Volume and directory path for the synchronization. The syncspec.ext portion of the Source specification should either be a specific file name and extension or a wild card pattern which will match ONLY the desired files. SYNCA2B.TSK // Check if a previously scheduled execution of this task has completed IF ACTIVE_TASK %TASK% ECHO. ECHO ERROR: %TASK% already active... (Local SYNC) ECHO. EXIT ENDIF // Check if a previously scheduled Remote Server SYNC has completed IF EXIST SYS:SYSTEM\SYNCB2A.TMP ECHO. ECHO ERROR: %TASK% already active... (Remote SYNC) ECHO. EXIT ENDIF // SYNC the files on this Local Server to the Remote Server // /a - Add any files on LServer not already on RServer // /m - Modified (newer) files are copied from LServer to RServer // /s - Subdirectory recursion (traverse directory tree) processing SYNC VOL:PATH\syncspec.ext [RServer]/VOL:PATH /a /m /s // Send a command to the Remote Server to launch SYNCB2A to // SYNC the files on the Remote Server to this Local Server TMSCMD [RServer] TMRUN SYNCB2A SYNCB2A.TSK // Check if a previously scheduled execution of this task has completed IF ACTIVE_TASK %TASK% ECHO. ECHO ERROR: %TASK% already active... (Local SYNC) ECHO. EXIT ENDIF // Copy this task to the Local Server as a temporary file // (indicating that the SYNC is in progress) SXCOPY %TASK_NAME% [LServer]/SYS:SYSTEM/SYNCB2A.TMP // SYNC the files on this Remote Server to the Local Server // /a - Add any files on LServer not already on RServer // /m - Modified (newer) files are copied from LServer to RServer // /s - Subdirectory recursion (traverse directory tree) processing SYNC VOL:PATH\syncspec.ext [LServer]/VOL:PATH /a /m /s // Send a command to the Local Server to delete the file we copied // (indicating that the SYNC is finished) TMSCMD [LServer] DEL SYS:SYSTEM\SYNCB2A.TMP SYNC options / support for GroupWise Post Offices Although the SYNC command does not have any special capabilities or features for GroupWise support, SYNC file replication and data synchronization of GroupWise systems for centralized backup and disaster recovery is performed regularly by a great number of TaskMaster sites. By utilizing TaskMaster's scripting capabilities, sites are able to shutdown and restart their Post Office in order to attain full access to the Groupwise files. Depending upon the environment, there are basically three ways to accomplish this task: Shutdown the GroupWise Post Office to perform a full SYNC of the Volume then restart the Post Office upon completion. This is the simplest method and works well when GroupWise access is not required during backup / off hours processing periods. Shutdown the GroupWise Post Office to perform a SYNC of just the GroupWise directory then restart the Post Office upon completion and perform a full SYNC, excluding the GroupWise directory. This is a popular method where GroupWise access is 24x7 and the Remote Server for the SYNC is on the same LAN or high speed WAN as the Post Office is down for a very short period. Shutdown the GroupWise Post Office to perform a SYNC of just the GroupWise directory to a backup directory on the local Server then restart the Post Office upon completion and perform a full SYNC, excluding the GroupWise directory. This method provides the least possible down time for GroupWise but requires sufficient local Volume space for a snapshot of the GroupWise Post Office. It is most often used where GroupWise access is 24x7, the Remote Server is on a slower WAN link and the local Server has plenty of Volume space. Whichever method is chosen, the process can be fully automated using the scripting capabilities built into TaskMaster. To assist with this effort, a sample task for shutting down a GroupWise Post Office to perform a SYNC of just the GroupWise directory then restarting the Post Office upon completion and performing a full SYNC, excluding the GroupWise directory, has been posted on the Sample Tasks page under the name SYNC-GW.TSK : http://www.avanti-tech.com/taskmstr/smpltask.htm#SYNC-GW Assistance is also available for creating a custom task or modifying any of the Sample Tasks in order to accomodate a unique environment or accomplish a specific task. How does SYNC handle open files? By default, SYNC attempts to access the local (source) file in an exclusive mode in order to insure the integrity of the data. By adding the /-E (disable Exclusive access) option to the SYNC command line, SYNC will attempt to access the local (source) file in a shared, read-only mode which allows many additional types of open files to be accessed. If the file is open by another Process or User in a non-shareable mode, SYNC will generate an error and terminate further processing unless the /I (Ignore non-critical errors) option has been specified. If the file is open in the remote (destination) directory, SYNC will attempt to non-destructively close the open file (i.e., without terminating the connection which has the file open) in order to update it. In most cases, SYNC is able to non-destructively close the open file and update it. In those cases where it cannot close the file, a error tag will appear in place of the typical [SYNC] completion tag. How do I copy a single file from the local server to a remote server so it ONLY copies if the local is newer (by date or time) doesn't copy if destination is exactly the same. I tried SCOPY and SXCOPY but it always copies whatever the date and time of the local. I tried SYNC but I think this is only for directories. While SYNC is used to process directories, a single file or a wild card specification can be used in the source specification to limit the processing to a single or group of files. For this situation, the following specification should be used: SYNC [vol:path/syncspec.ext] [server/vol:path] [option(s)] The syncspec.ext portion of the source specification should either be a specific file name and extension or a wild card pattern which will match ONLY the desired files. The following [option(s)] SHOULD be specified depend upon the criteria desired for the comparison of the source and destination files: /A will copy the source file ONLY if it does not already exist in the destination directory /M will copy the source file ONLY if its date/time stamp is newer than that of the destination file /V will copy the source file if there is ANY difference in the date/time stamps or sizes between the files Note: /V will process files matching the /M criteria The [option(s)] which SHOULD NOT be specified include: /D will delete any files in the destination directory which DO NOT match the source specification, thus leaving only the matching file or group of files in the destination directory /S will recursively process sudirectories, not necessary for a single file or group of files in a single directory What triggers the synchronization of Trustee Rights? As documented in the User's Guide, synchronization of DOS/NetWare Attributes and Date/Time stamps occurs whenever files are created or updated. In addition, Ownership and Trustee Rights are also synchronized by default if both the source and destination reside in the same Directory Tree. This assures that complete synchronization occurs whenever data changes. Note: The /O (Ownership) and /T (Trustee Rights) options are enabled by default within the same Directory Tree, even if not specified. Disabling the transfer of Ownership and Trustee Rights is accomplished using the /-O and /-T options, respectively. Even when data changes have not occurred, TaskMaster SYNC analyzes the Extended Attribute Archive bit for each dir/file to determine if an Extended Attribute, Owner, or Trustee Right has changed. The problem lies in the fact that this attribute is set by NetWare the first time any of these changes occur and is only reset manually or programmatically (i.e., once set, it is not reset by NetWare and it is not a value or index which is incremented or adjusted so that a program can detect subsequent changes after the first without the bit being reset between each change). Initially, we intended to reset the Extended Attribute Archive bit after each SYNC to make it easier to detect subsequent changes. However, Novell indicated that SMS Backup Developers also rely upon the Extended Attribute Archive bit to determine files which need these aspects updated. Therefore, to avoid adversely affecting Backup products, we only compare the bits and update the information when there is a discrepancy between the source and destination. Once the information is updated, the destination bit is set to match the source so that the same update is not repeated every SYNC since it is unlikely that the information has changed. When Backup software toggles the Archive attribute, the Extended Attribute is typically reset at that time. The same thing happens when TaskMaster's FLAG command is used to reset a file to N (Normal) status (i.e., Rw, not Archived). A survey of TaskMaster Users revealed the following facts about Trustee Rights: 1). They are more commonly assigned to Directories versus Files (typically reducing the number of overall operations required); 2). They are not used that widely (i.e., only a small percentage of sites assign Trustee Rights and they are assigned to a very small fraction of the overall dirs/file; And, 3). They do not tend to change as frequently as data changes occur. Based upon this criteria and SYNC's current analysis, the vast majority of all Trustee Rights changes are properly updated. The exception will be multiple Trustee Rights changes to an unmodified file between scheduled Backups (i.e., most often encountered when Trustee Rights synchronization is being tested during a short period between scheduled Backups using an inactive file).