Release Notes: IBM Aspera Sync 3.7.3 for Windows and Linux

Product Release: April 21, 2017
Release Notes Updated: April 21, 2017

This release of IBM Aspera Sync provides the new features, fixes, and other changes listed below. Additional sections cover system requirements and known problems.


  • On Windows machines, synced files inherit the ACLs of the destination folder.
  • Sync now has a two-minute timeout, enabling it to exit gracefully in the rare cases when under high network impairment conditions Sync does not receive a proper shutdown sequence.
  • The asyncadmin tool can now output file and session status when Sync is using a database with LMS (<async_db_spec> is set to sqlite::lms). When reporting data on a specific source-destination pair by name (using the -N pair_name option), if Sync is running then the output reflects the final state of the last async run and does not reflect any changes in the active sync.
  • Sync run in bidirectional mode with modification times preserved no longer reports conflicts due to directory modification times. However, when the source and destination directory times are both modified between sync sessions, directory modification times might not be preserved.
  • On machines with Unix-based operating systems, a new value, inode, is available for the --dedup option. In this mode, when two or more source files have matching inodes, a hardlink is created between them on the target and the target files have matching inodes.
  • Faster Snap database loading on subsequent syncs when many (100s) of filters are specified.
  • Faster execution of --dedup=copy on Windows machines that support Offloaded Data Transfers (ODX).
  • Sync with S3 is now fully supported and documented.
  • Improved Sync shut down process when a Sync session is stopped.
  • Bidirectional syncs between S3 buckets are now supported.
  • A new option, --cooloff-max=time, can be specified so that a one-time Sync waits for a file to stop changing within the cooloff interval before it synchronizes the file. With this option, the file is skipped after the cooloff-max time.
  • Sync sessions can now be filtered by setting the <filter> configuration in aspera.conf. Command-line filters are applied after aspera.conf settings. If filtering is not always wanted, then configure filters for one user. Sync sessions that are run by that user are filtered while sync sessions run by other users are not.


Note: This release contains tickets that were created from different issue-tracking systems. For this reason, the list below uses two different formats for issue numbers.

ES-238, WAT-520 - When a client-side asyncsession is forced to quit, in rare cases the server-side async process may not stop. (CIM-364)

WAT-538 - [Windows, Linux] Renaming a folder during a continuous, bidirectional Sync session with scan-interval enabled can cause a conflict with the folder.

WAT-512 (#29038) - The --overwrite older option of Sync does not recognize modified files if the size has not changed and they are in storage that does not support sparse checksums, such as Azure cloud storage, or when async is run with the --checksum none option.

WAT-502 - [Windows] Sync cannot compress non-ASCII characters and hangs if the option --compression=zlib is used on files with non-ASCII characters in the file names or paths. (CIM-465)

WAT-453 - Watchd is unable to read folders on a machine running Windows 2003. Note:Windows 2003 support was discontinued in 2015. (CIM-361)

WAT-449 - Sync does not respect the cooloff option.

WAT-442 - Sync does not stop if filters have been configured in aspera.conf and one or more files in the sync session match a filter.

WAT-430 - When async is run with the option --symbolic-links=skip, errors are logged for each symbolic link encountered.


  • Windows: Windows 7, 8, 10, or Windows Server 2008 R2, 2012 R2, 2016
  • Linux 64-bit and 32-bit: Ubuntu 12-15, RHEL 6-7, CentOS 6-7, SLES 11-12, Debian 6-7, Fedora 16-20; Kernel 2.4 or higher and Glibc 2.5+


Linux 64-bit (rpm): aspera-sync-
md5: acc7ef9b7bfd43c266b64010e5970181
sha1: fa7e210db99d3c6c2eb845b7459a646062f98f69
md5: d83702edf02615e53d96c38ebdc90445
sha1: 96df21ca0a81fa0a931f747b953e48b0f04e1d36


Note: This release contains tickets that were created from different issue-tracking systems. For this reason, the list below uses two different formats for issue numbers.

ES-92 - Sync reports incorrect counts for 'deleted_paths', 'deleted_bytes', and 'cumulative_deleted_bytes'.

ES-50 - When using local storage for Sync with Files on Unix-based systems, Sync fails if the access key storage does not start with "/". For example, data/storage fails but /data/storage is successful.

WAT-523 - Meta-attributes are not preserved in sync sessions that use the --dedup=copy option.

WAT-465 - Sync hangs following a TCP impairment that produces a libssh2 timeout or error.

WAT-377 (#27391) - [Linux] A continuous async session that is configured to follow symlinks does not sync a symlink file after it is modified.

WAT-362 (#24812) - [Windows, Linux]If a file's size decreases during a continuous Sync push, the file remains pending and is never synced.

WAT-355 (#34793) - [Windows] Hard-linked files are not resynchronized. A file that is a hard link to another file is kept in sync until the original file is modified, then only the original file is synced.

WAT-288 (#27311) - An --apply-local-docroot pull copies the local docroot path into the same path. For example, /home/user1/sync is copied into /home/user1/sync.

WAT-287 (#32064,#32883) - [Windows, Linux] When syncing a directory in continuous, bidi mode, Sync keeps running with one pending file rather than complete and go idle.

WAT-9 - When the scan-file-rename option is used with asperawatchd, moved files should be detected and renamed at the destination, not deleted and replaced by a transferred, renamed file.

#29038 - Using overwrite=always when syncing with cloud storage does not overwrite the file. The default checksum behavior with S3 (as with any cloud storage) is "none". An existing file on S3 is considered identical to the local file when their sizes are equal. Therefore the file on S3 is not overwritten, even when the content of S3 differs from the content of the local file.

#28817 - The Sync log entry for SYNCERROR_DELAY does not include information that describes the file name and path.

#27621 - Sync reports conflicts due to the presences of hidden, temporary, or transient files (such as temporary files created by Microsoft Office products).

#25915 - [Linux] If a source file is overwritten during a continuous Sync in push mode, the corresponding file on the destination might be deleted. Workaround: Run a one-time push Sync of the overwritten file to restore it on the destination.

#25631 - When transferring from Windows to Mac using preserve-acls=native and remote-preserve-acls=native, ACL data are saved as xattr. Workaround: Do not use the nativesetting when transferring or syncing across platforms.

#24805 - ACL data are preserved at the destination for all files and subdirectories in the source folder, but ACL data for the source folder itself are preserved at the destination.

#23954 - When the --preserve-acls or --preserve-xattrs option is used, async does not preserve the acl or xattr when either file acl or xattr is modified and (a) file content is unmodified or (b) file content is unmodified and the file is renamed.

#23400 - [Linux] As of Sync version 1.5+ the user is permitted to sync to the root directory.

#23004 - Aspera Console does not draw a line between the involved nodes for an asynctransfer. This issue occurs when two managed nodes are used with two interfaces on two different networks.

#22633 - Sync does not support large xattr/ResourceForks.

#22044 - asyncadmin reports all sessions are locked after the last actual running session.

#21014 - When creating a file with vi during a sync, the swap file is in conflict.

#20906 - async cannot create a watch on an unreadable directory; therefore, it does not get notified when permissions change. In addition, async treats an unreadable directory as "skip" rather than reporting an error or conflict.

#20767 - -R log dir creation from Linux to Windows with spaces in the path will only get as far as the first space in the path.

#20347 - Async reports errors and conflicts for deep directory depth when the sync is from Linux to Windows.

#19945 - asyncadmin creates SHM and WAL files for read-only operations. Once asyncadmin is run as the root, async run by the user does not have permission to access the existing SHM and WAL files and thus async fails. This is due to a bug in SQLite.

#18780 - [Linux] An async push conflict occurs when a new file is renamed quickly.

#16911 - Characters in the async session option that are not preceded by a "-" or "--" are ignored, therefore failing to trigger an error message. Any session options specified (such as -lor -a) after the string of characters not preceded by a "-" or "--" are also ignored. The session still runs using the default values, but does not notify the user that the command line settings have not been applied.

#13826, #13827, #13833 - [Windows] Limited support for Unicode file names on Windows: The user creates a directory with a name containing Unicode characters (for example, Japanese), and then creates a file in that directory. The following errors may occur:
  1. Running with an -N set to a string with non-English characters (such as Japanese) causes an error message.
  2. After a sync, the UI displays an inaccurate directory name and path separator.
  3. After syncing, using the asyncadmin -M option does not allow the user to delete the file from the database.

#13761 - If file names contain "\" or new line, async will try to transfer but fail, causing the internal transfer queue to become full and the synchronization to stall (or hang after all the other files have completed).

#13645 - When a directory is renamed during transfer, Sync continues running and never completes.


For online support resources for Aspera products, including raising new support tickets, please visit the Aspera Support Portal. Note that you may have an existing account if you contacted the Aspera support team in the past. Before creating a new account, first try setting a password for the email that you use to interact with us. You may also call one of our regional support centers.

Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk