Reproduced this problem by trying “direct restore” of an old Linux backup using Windows Duplicati FTP. Used package inetutils-ftpd as an FTP server. The error from About → Show log → Live → Retry was:
Jul 4, 2019 10:02 AM: Operation Get with file duplicati-20181124T033217Z.dlist.zip attempt 5 of 5 failed with message: The file duplicati-20181124T033217Z.dlist.zip was downloaded and had size 2206 but the size was expected to be 2201
Below is how this dlist slowly grew by 5 bytes by translating Linux LF (0a) line endings to CR LF (0d 0a):
00000070 68 60 64 62 60 00 15 f2 48 2c ce 00 aa 0a f6 70 h`db`...H,.....p
00000070 68 60 64 62 60 00 15 f2 48 2c ce 00 aa 0d 0a f6 h`db`...H,......
00000440 11 f7 c9 39 18 0a c9 4d 43 05 ae a8 9d 4d b4 f5 ...9...MC....M..
00000440 d1 11 f7 c9 39 18 0d 0a c9 4d 43 05 ae a8 9d 4d ....9....MC....M
00000610 0e 14 ac 59 2b 0a 7e 13 6d b5 3e 56 f8 dd 50 36 ...Y+.~.m.>V..P6
00000610 7a 9a 0e 14 ac 59 2b 0d 0a 7e 13 6d b5 3e 56 f8 z....Y+..~.m.>V.
00000620 69 5c 2c 0a c7 08 db 1b f8 1c ae 0d ce 65 2c c2 i\,..........e,.
00000620 dd 50 36 69 5c 2c 0d 0a c7 08 db 1b f8 1c ae 0d .P6i\,..........
000007d0 a0 44 84 cc 4d 1d ce be f6 53 34 df df a4 7e 0a .D..M....S4...~.
000007E0 df a4 7e 0d 0a 07 84 20 42 85 70 04 41 c1 45 38 ..~.... B.p.A.E8
FRITZ!OS is Linux-based, and the problem might be only on UNIX-like FTP servers. Windows already treats CR LF as its line ending, so no conversion for it is required. What to do for a CR without a LF in original source is controversial. The standard wants CR NUL, but the problem is NUL is troublesome. Regardless, the FTP server I used for the test left simple CR alone, and only translated LF into CR LF.
If any development volunteers know FluentFTP, feel free to join. I haven’t found the source-level cause, however if it turns out to be a third-party library bug, I hope there’s some workaround Duplicati can use.