Sat, Nov 5, 2016
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!
Sun, Apr 5, 2015
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.
Sun, Dec 14, 2014
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
Sat, Apr 12, 2014
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
Sun, Dec 23, 2012
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.
Sat, Mar 10, 2012
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!
Tue, May 17, 2011
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).
Tue, May 17, 2011
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.
Mon, Apr 26, 2010
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.
Sat, Apr 10, 2010
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).
Wed, Jul 1, 2009
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.
Sat, May 30, 2009
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.
Wed, Nov 26, 2008
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.
Tue, Sep 16, 2008
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.
Sat, Aug 23, 2008
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).
Sun, Jul 20, 2008
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.
Thu, May 8, 2008
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.
Mon, Apr 2, 2007
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.