FreeFileSync Forum

> 1. The estimated time for completing was more than 1 day!

Statistics for remaining time in FFS are based on file size only. This has the side effect that deleting files creates a distortion, because this is seen as "no bytes copied", but it still takes some time.

> 2. At some point the trash ...

I'm using now the 6.6 version from the debian build (FreeFileSync_6.6_Debian_7.5_64-bit.tar.gz)

The daytime saving issue uncovered another problem.
I decided to sync again a whole directory of 17 Gb and 46000 files. Note >95%
of the files were actually the same, just the 1h difference.

Two problems:
1. The estimated time for completing was more than 1 day!
2. At some point the trash can got ...

The disk I use to backup to is an external 2Tb FAT32, and the files are copied from another external
20 Gb NTFS disk and sometimes from the ext linux partition.
Am I *always* going to have this issue with this disk? I can't believe it came
as a FAT32, I did not format it myself. Is there any ...

This project is reported in
http://www.ohloh.net/p/freefilesync
as of very low activity. Is it abandoned?
Thanks

I have lots of files marked to be copied that have just 1h of difference with those
that had already been synced in the past.
I guess this is the saving time problem again, was this problem not fixed?
Is there a fix to avoid copying all this files? I'm using
5.23 on linux.

Same problem here. No solution to this problem? I remember having had this
problem in the past but though was a fixed bug.

I have had the same problem with FAT32, both windows and linux (ubuntu 10.04).
Would the same fix work? And most important, does this fix have any collateral effect?
I mean, setting a large file time tolerance looks like a potential problem (i.e., new files not being copied).
Thanks