Superflexible changes my dates to a year in the future

[robeerski]

I have been using version 5.5. I am using superflexible to perform a bidirectional sync between files on my hard drive and an FTP site. Twice in the past two months I have had superflexible modify all of the synched files to have a date one year in the future. This means that now all of the files it synched have a 2012 date on my hard drive instead of a 2011 date. The month and day in the date are not affected. What then happens is future syncs always assume that my files are newer then the ones on the FTP site and it overwrites new data on the FTP site with old data on my hard drive because my files have a 2012 date when they should have a 2011.

I am wondering if anyone else has had this problem. I also upgraded to ver 5.6 today and I wonder if this new version may have fixed this problem. I am also curious how to stop this from happening in the future as it makes my sync kind of useless.

I'm not sure about the first time this happened but the second time this happened superflexible had a hard time accessing my local shared drive and there were errors in the log. I just don't understand how errors accessing my local shared drive causes the file to come in at exactly one year further in the future then the actual file date on the remote FTP site.

[superflexible]

This must be an FTP compatibility problem. Unfortunately FTP listings are not standardized properly, and many timestamps are given without the year. So, depending on the current date and time, the program needs to guess which year is meant. That logic was indeed improved a while back, so it would be interesting to know if the problem goes away with the latest update.

Do you still have the log file from a run where this occurred? If so please send it to info@superflexible.com.

Until this is resolved, you should run the job manually only and look at the Sync Preview to check if the dates are correct. You can also change the copying direction on the preview as needed.

[superflexible]

It turned out that the automatic server timezone detection was part of the problem. The latest version of the software fixes this.