Release Notes: IBM Aspera Sync 3.7.2

 
Product Release: January 13, 2017

Release Notes Updated: January 13, 2017

This maintenance release of IBM Aspera Sync provides the fix listed below.

ISSUES FIXED IN THIS RELEASE

WAT-333 - [Windows] async sessions started with the Windows Task Scheduler are not stopped if asyncadmin -T is run by a user other than the user running the current sessions.

SYSTEM REQUIREMENTS

Windows:  2008 R2, 2012 R2, 7, 8, 10

Linux 64-bit and 32-bit: Ubuntu 12-15, RHEL 6-7, CentOS 6-7, SLES 11-12 Kernel 2.4 or higher and libc version GLIB 2.3.4+, Debian 6-7, Fedora 16-20

PACKAGE INFORMATION

Linux 64-bit (rpm): aspera-sync-3.7.2.137926-linux-64.tar
md5: 239ffca1fc7755092775caa7c82a2614
sha1: 41ad3349d584b694c5dba78bf9c0cbc7e6a44daf
Windows: aspera-sync-3.7.2.137926-win-v100-32.zip
md5: 178c04abbf7fadb66a8352834190417a
sha1: b9ec2a5d451894fa7bbc9fbe055920313bf47530

KNOWN ISSUES

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

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-377 (#27391) - [Linux] A continuous async session configured to follow symlinks will not sync a symlink file after it has been modified.

WAT-362 (#24812) - 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) - 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.

#28887 - When a file or directory is moved using the --exclude command in Sync continuous mode, the old file or directory is not removed from the remote side.

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

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

#25915 - When the sync function is set to continuous, overwriting an existing file on the initiating node may result in the deletion of the previous version of the file on the responding node. Workaround: Perform the sync manually to recreate the deleted file.

#25913 - Aspera Drive attempts to sync a file that is still uploading to Shares, resulting in a file error.

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

#25467 - async cannot be used with cloud storage.

#24805 - For a synced directory, while all of the files and subdirectories under the source folder will have ACL preserved at destination, the ACL for the source folder itself will not be replicated to the remote destination folder.

#24780 - Both --preserve-acls and --remote-preserve-acls must be specified in order for the target side of the pull to apply the acls.

#23954 - When the --preserve-acls or --preserve-xattrs option is used, async will 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 - Console does not draw a line between the involved nodes for an async transfer. This issue occurs when using two managed nodes with two interfaces on two different networks.

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

#22044 - asyncadmin reports all sessions 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 can't 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.

#18913 - Cancelled or stopped jobs are reported as completed in fasp_sessions.status.

#18780 - 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 -l or -a) after the string of characters not preceded by a "-" or "--" are also ignored. The session will still run, using the default values, without notifying the user that the new settings have not been applied.

#13826, #13827, #13833 - [Windows] Limited support for Unicode filenames on Windows: The user creates in 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 performing 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 filenames 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.

#9126 - Async logs events at a fast rate. The log destination must have room for large log files.

PRODUCT SUPPORT

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

0 Comments

Please sign in to leave a comment.
Powered by Zendesk