Purge operations result in broken dlist files #3924 is IMO a show-stopper/backup-breaker and repair
can also cause it. Fortunately, there is some progress on it, so possibly this issue will leave the blockers list…
Regarding the new mono requirement of v5, I hope that at least the release notice publicizes that. Canary test has seen about 4 incidents of older mono, with 2 having Duplicati crash, and 2 needing a newer TLS.
Although I think package maintainers should update dependencies, and ideally autoupdater would test too, maybe we can survive without that. I don’t like it, but decided above to yield and find out how Canary fared.
“FTP (Alternative)” breakage is a regression I have a hard time quantifying, but aftp
is somewhat rare and “FTP” can often substitute for it. In addition I think the SIZE
command getting in trouble requires the server to be non-compliant with the File Transfer Protocol standard in RFC 959 transfer parameters requirement:
4.1.2. TRANSFER PARAMETER COMMANDS
All data transfer parameters have default values, and the
commands specifying data transfer parameters are required only
if the default parameter values are to be changed. The default
value is the last specified value, or if no value has been
specified, the standard default value is as stated here. This
implies that the server must "remember" the applicable default
values.
Specifically Windows 10 Duplicati aftp talking to inetutils-ftpd
on Linux was given an ASCII size even though the transfer parameters had previously been set to image
. I tested vsftpd and it gave a binary size, which made me hope that most modern FTP servers would do OK. But there are lots, I tested no further, and there’s no telling what sort of old crufty FTP might be in a NAS that’s still also using old crufty SMBv1. Needing a size-check workaround at all bothers me, e.g. why is it needed and does transfer time matter?
I can try to do better on instructions, but it’s easy. I think I backed up a 1 byte and 4 byte file, no encryption.
On release process matters, there’s also a Duplicati version numbering proposal with some good ideas, extending my Release: 2.0.4.23 (beta) 2019-07-14 idea of leaving some number space for beta patching.