Created attachment 235964 [details] Patch for rsync This reduces download size slightly and should prevent duplicate entries when using make makesum Tested on FreeBSD 13.1-STABLE #0 stable/13-n251817-0c4d13c521a
Created attachment 235965 [details] Patch for rsync v2 Refresh patch
rsync usage here which worked the same for over a decade suddenly fails between the port 8 10 2022 and 8 19 2022: if not a failure to copy because of a file with a tilde at the end, and not informing WHERE that file may be found, and if on the source or destination, ... then fails with an io.c [32] error code, broken pipe. I had to copy a 8 16 rsync from backup to the source to continue using it.
(In reply to J. B. from comment #2) Hi, That should be submitted in another PR along with relevant information and how to replicate Best regards, Daniel
(In reply to Daniel Engberg from comment #3) (In reply to J. B. from comment #2) Agree with Daniel, this is another issue In new PR don't forget to fill a complete and accurate description of the issue you are experiencing with : * a description of your environment, OSs versions the file systems in both sides (UFS/ZFS/NFS) and the files you are copying * The full command you type, with all the switches, you can of course hide the sensitive datas such as account name, IP address or DNS names * The full error messages * If possible, the steps to reproduce the error This will help with the analysis. Regards -- rodrigo
Well, in seamonkey, firefox, and iridium, once logged in the "file bug" refuses to accept any input in the portname box, so it is at least today imnpossible to input "net/rsync" to start the bug process. root/.local/share/recently-used.xbel rsync: [sender] write error: broken pipe (32) rsync error: error in socket IO (code 10) at io.c(845) [sender=3.2.5] rsync error: received SIGUSR1 (code 19) at main.c(1619 [generator=3.2.5] .... # rsync --vaHAXS --delete-delay --partial --stats --numeric-ids --inplace --archive --backup --one-file-system --hard-links --bwlimit=9000 --specials --exclude-from="/usr/ [some file ]" . /destination ; kldload speaker; yell ....... I had to force reinstall rsync to replicate this error, the rsync I am using is from a few weeks ago that I got from one of my backups. ..... I am copying the four main filesystems one by one, here / .... /dev/gpt/root_backup is mounted on /destination ... 13.1-STABLE GENERIC amd64 stable/13-97fe61d5b [unsure of the digit following 6] .... after I log out I will overwrite the newer rsync with the previous one... 3.2.4 works as expected 3.2.5 repeats this io.c error. ..... Sorry for not being able to file on the webpage as I detailed above, it suddenly does not accept port name input.
Rodrigo, is this good to go?
(In reply to Daniel Engberg from comment #6) Hi Daniel, First, thanks for your patch, but I'm sorry, for now we can't go with this fix. You aren't probably aware but the rsync tar archives aren't the exact copy of the git repo, but pre-processed files. As a result, the archived ones has less build dependencies, and some new pre-generated files. We have the same behavior for the extra-patches, where files differs (eg. fileflags.diff archive has an additional fix for rsync.1 manpage) I keep the the changes you made to modernize the Makefile on the side to be applied on next rsync update, no need to force peoples to upgrade rsync just for that. My feeling is we can solve the issue by fixing the ports scripts and remove duplicate entries in distinfo file during its generation. I did it one, a dirty fix I never submit and unfortunately I miss the code. I will try to do it again :p
Issue fixed in rsync port by commit 1f2f7227e8ca9c91872adf2d3b67c69dda097961