I don't know how to attach images here, so I'll just leave this note here:
I think there is something wrong with the calculation of one or more of the sync parameters.
I have a sync job running and this is what the status window shows:
900,35%
Verbleibende Elemente: 52.058 (-566 GB)
Geschwindigkeit: 1,76 MB/s
Verbleibende Zeit: -88829 Sek.
Vergangene Zeit: 15:24:43
The sync is completed now. Status window shows:
Verarbeitete Elemente: 1.117.456 (648 GB)
Verbleibende Elemente: 0 (-577 GB)
Geschwindigkeit: 11,4 MB/s
Gesamtzeit: 16:06:26
FFS projected a total sync size of about 70 GB IIRC. This is in the range of 648-577=71GB. So does the percentage: 648*100/71=912%. The negative remaining time may simply be a result of a negative remaining size.
I have saved the file list before syncing, but it's pretty huge. If you need information from it, i could try to analyze its contents.
Percentage / size remaining / time remaining bug in 5.18
- Posts: 14
- Joined: 14 Sep 2012
- Posts: 14
- Joined: 14 Sep 2012
Uh oh.
I analyzed the file list. Basically, I was doing a one way sync from lhs to rhs with lots of moves, some new and some deleted. Everything else is insignificant or not present.
Stats:
create -> 71 GB
move from -> 649 GB
move to -> 649 GB
delete -> 210 GB
This lets me think the move detection kicked in, but it didn't actually move files. I can't explain at the moment why the total size wasn't in the 720 GB range though.
Edit:
Can't reproduce with a simpler example at the moment.
Nothing too complex on my original drives, some hardlinks, but mostly simple files.
The log is too short to reveal anything meaningful.
I analyzed the file list. Basically, I was doing a one way sync from lhs to rhs with lots of moves, some new and some deleted. Everything else is insignificant or not present.
Stats:
create -> 71 GB
move from -> 649 GB
move to -> 649 GB
delete -> 210 GB
This lets me think the move detection kicked in, but it didn't actually move files. I can't explain at the moment why the total size wasn't in the 720 GB range though.
Edit:
Can't reproduce with a simpler example at the moment.
Nothing too complex on my original drives, some hardlinks, but mostly simple files.
The log is too short to reveal anything meaningful.
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
I can confirm this is caused by a problem related to file moves. FFS 5.18 contains a regression where file moves are not applied when the parent directory is deleted. Except from being inefficient, this causes the strange symptoms you described of FFS copying more data than expected. This had been fixed in the meantime for the next version:
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.19_beta_Windows_Setup.exe]
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.19_beta_Windows_Setup.exe]
- Posts: 14
- Joined: 14 Sep 2012
Thanks!
