FTPSync 2.10.0 RC1 released

Today, I released FTPSync 2.10.0 release candidate 1. Please note, this is release candidate, NOT a final release! It has not been fully tested, and is intended for evaluation and testing by early adopters, and not recommended for use in production environments, yet. Due to changes in internal structures and .MTB files, you can upgrade your existing setup to this version, but will not be able to downgrade to FTPSync 2.9.x, without doing full transfer or backup/restore your .MTB files to state before upgrade!

FTPSync 2.9.13 released

Today, I released CyberKiko FTPSync 2.9.13. New or updated in this release: Fixed issue that in some cases resulted in incorrect Return/Error code. For more information on changes in this and previous releases, please refer to History.

DeleteMe 1.5.1 released

Today, I released CyberKiko DeleteMe 1.5.1. New or updated in this version: added “zero day” cleaning option: if set to zero days, DeleteMe just removes all files from a directory on every run, without checking if files have been changed fixed an issue that may have caused a reset of the list of temporary directories

FTPSync & Heartbleed

FTPSync uses OpenSSL, however the version used in current version of FTPSync is 1.0.0d, and this version, according to the researchers, is not vulnerable to Heartbleed bug. If you use FTPSync version downloaded from official site, than you are safe. However, if you have replaced OpenSSL provided with FTPSync with newer release of OpenSSL then please check if the release used is safe! More details on Heartbleed bug are available

How to use FTPSync in two way sync scenarios

FTPSync is a one way sync tool, that is, files are always transferred from source to destination. Due to its “blind sync” algorithm, it can not be used in two way sync scenarios, by defining two transfers, where one syncs from source to destination and the other vice versa. However, by following a simple rule, that each file goes one way only, FTPSync can be used in certain two way sync scenarios.

Directory Digest 1.4c released

Today, I released CyberKiko Directory Digest 1.4c. New or updated in this version: fixed ‘illegal compare route’ error, when comparing digests with subdirectories containing files with same names; relative paths are now included in digests/reports IMPORTANT: Due to changes in digest, some files that are the same may be reported as different, when comparing digest created with Directory Digest 1.4c or later with digest created with Directory Digest 1.4b or earlier!

FTPSync 2.8f changed requirements

Starting with FTPSync 2.8f, FTPSync requires Microsoft .NET Framework. This is not an issue with users running Windows Vista, Windows 7 or Windows Server 2008, as those systems come with .NET preinstalled. Most Windows XP or Windows Server 2003 systems also have .NET installed, as many newer applications require it. If your computer does not have .NET installed, you will have to install it to run FTPSync 2.8f or later. The minimum required version is 2.0, although it is recommended to install the latest version available for your operating system (at the time of this post, version 4.0 is available).

FTPSync on UserVoice

To make it easier to provide feedback on FTPSync or request a new feature, I’ve set up FTPSync UserVoice site. It is accessible from FTPSync’s page via feedback tab on the left or via a link on a support page. I’ve also populated it with some often requested features, for a start. I hope this will make it easier for users and me to track those requests.

FTPSync Dummy Files utility

One of the issues with FTPSync is that its sync algorithm is file based, not directory based. As a result, empty directories are not transferred. This seems to be increasingly a problem lately, as some frameworks, blog engines, etc. rely on their directory structure, even if directories are empty. For this reason, I’ve raised my task to change sync algorithm to the top of my list. In the mean time, if you are affected, and if source of your transfer is file system, you can work around this problem by using a simple utility, I’ve called FTPSync Dummy Files (FSDF) tool - it scans a directory structure and adds ftpsync.dummy file in every empty directory, ensuring that all your directories will be transferred.

FTPSync RetryCount/RetryDelay issues

There are some issues in FTPSync regarding RetryDelay/RetryCount parameters. A combination of a bug in counting routine along with a bit unclear algorithm on how counting is done may result in vary strange behavior, where number of times to repeat an operation can be way different than what is set in RetryCount parameter. For this reason I’ve redesigned the algorithm. The RetryDelay/RetryCount parameters are now strictly used for a single item (directory or file).

FTPSync: No files are transferred when IncludeRoot=No is set

A bug was introduced in FTPSync 2.8c, which may cause FTPSync to transfer no files at all, when IncludeRoot=No is set. This issue has been resolved in FTPSync 2.8d.

FTPSync ignores AllowModeZ=No

There is a bug in FTPSync 2.8c, which in some cases may cause FTPSync to ignore AllowModeZ=No and continue to use MODE Z (compressed transfers) for some FTP server operations. If your FTP server is having issues with MODE Z, this may result in frequent timeouts, dropped transfers or complete inability to use FTP server. This issue has been resolved in FTPSync 2.8d.

FTPSync: File size limits when transferring large files

FTPSync by itself does not impose limits on file size to be transferred. However, due to firewalls prematurely timing out FTP sessions, it’s possible that your specific setup may impose a file size limit, which may be as low as several MB and as high as several GB. Usual symptoms are: file is transferred completely or almost completely (byte count gets close to file size), when transfer should end, FTPSync “hangs” for a minute or two, an error (426 Transfer aborted or similar error) is displayed instead of successful transfer.

FTPSync: Avoiding initial transfer of all files

When you run FTPSync for the first time, it will transfer all the files from source to destination. The reason for this is the way FTPSync determines files that should be transferred, which is done by comparing the snapshot of source directory from previous transfer with current state of files in source directory - files that do not match are considered changed and will be transferred. When you run FTPSync for the first time, no snapshot from previous transfer is available, thus all files are considered changed and will be transferred.

ExcludeDir handling in FTPSync 2.8b and earlier

One of the issues that confuse users of FTPSync the most (at least judging from the feedback) is how ExcludeDir parameter is handled. Many users are surprised when they see FTPSync retrieving a directory they specified as excluded. However, in older versions this is by design, since FTPSync does the processing in the following sequence: directory tree with all files and subdirectories is retrieved excluded files and directories are processed and removed from transfer list transfer is performed In some cases this is a problem: if the directory that was excluded is somehow inaccessible to the user, which may cause FTPSync to fail (using IgnoreFailedDirs sometimes help) or if you exclude a large part of your directory structure, as FTPSync wastes time to retrieve it I’ve therefore started to re-organize the code, joining steps 1 and 2 (with plans to join step 3 later, too).

FTPSync: /INCREMENTAL command line parameter may be rejected

A bug has been found in FTPSync, which may cause it to reject /INCREMENTAL command line parameter. If you are using /INCREMENTAL command line parameter, like: FTPSync myinifile /INCREMENTAL you should instead call FTPSync without it: FTPSync myinifile because this is default parameter and is not needed. This will work always and prevent you from running into “Illegal parameter” error. This issue has been resolved in FTPSync 2.8b.

FTPSync: Running out of free space in temporary directory

While you may use FTPSync on any drive and directory on your system, FTPSync uses system’s temporary directory (usually C:\Windows\Temp) for temporary storage during transfers. This sometimes becomes a problem, if you transfer large files and your system partition does not have enough free space. In this case transfers may fail, even if you have more than enough free space on your destination drive. This issue has been resolved in FTPSync 2.8a.

FTPSync: Priority parameter

I’ve noticed that many people who send me their .INI files when asking for help/support with their issues, include “Priority=Idle” line. In most cases you SHOULD NOT set Priority parameter, as normal priority will work best in most cases. Set this parameter only if your source and destination is file system and only if you are sure setting it will give you perfomance benefit. If source or destination is FTP server, downloading/uploading to FTP server is very slow comparing to other processes, so FTPSync gives other processes enough time, regardles of this parameter.