Package: rsync Version: 3.2.3-4+deb11u1 Severity: minor X-Debbugs-Cc: debbug.rs...@sideload.33mail.com
Rsync was producing some baffling behavior. But after some investigation, it turns out rsync is apparently well-behaved. The docs are lacking in ways that slowed down my ability to figure out what was going wrong and hindered my ability to work out the needed parameters going forward. In the case at hand, I ran a command like this: $ rsync -va -P $local_source_file $local_destination A ~20gb file was being pushed through a USB2 bus which can be quite slow. I had to shutdown in the middle of the transfer thus hit ctrl-c. The partial file was left as expected (though hard to find because the date was 1970 and I did an “ls -ltr” to look for recent files). So at first I thought the partial file was not saved. This caused me to distrust ctrl-c as a signal that would be treated as an “interruption” (vs. a deliberate cancelation by a user which might cause an assumption that the user does not want the effects of the transfer to play out). Kill signals are not well documented. I later realized the partial file was in fact present but with a 1970 timestamp. Then I later ran the original command, but it started transferring from zero and did not crash-recover. Again I was astonished and thought there was a functionality bug. It’s finally clear that there are no functionality bugs in this episode. In the interest of mitigating user astonishment, I suggest the following man-page updates: 1. The docs for --partial should state the requirements for crash-recovery to function. Specifically, it should state that -W must be switched off in the recovery session. This is particularly important because it’s certainly not obvious from the summary of options that there is interplay between -W and --partial. 2. The docs for --whole-file should also mention its affect after --partial is used. Someone searching the man-page for partial should also be brought to the --whole-file option, and vice versa. The docs for --whole-file also neglect to state how to disable the option. The only reason I was able to discover the existence of the --no-whole-file option was because it incidentally happened to be an example given in the docs for --no-OPTION. Otherwise if that example had not existed, I would have been at a dead-end. 3. Man-pages normally have a “SIGNALS” section. I looked for that section because I wanted to see what signal results in a graceful abort that respects the --partial option. So a “SIGNALS” section should be created with that in mind. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rsync depends on: ii init-system-helpers 1.60 ii libacl1 2.2.53-10 ii libc6 2.31-13+deb11u5 ii liblz4-1 1.9.3-2 ii libpopt0 1.18-2 ii libssl1.1 1.1.1n-0+deb11u3 ii libxxhash0 0.8.0-2 ii libzstd1 1.4.8+dfsg-2.1 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:8.4p1-5+deb11u1 ii openssh-server 1:8.4p1-5+deb11u1 ii python3 3.9.2-3 -- no debconf information
