Patch to revive tmpfiles

[Hans Eric Sandström]

This is a patch to fix one annoyance of having rsync processes race:

I usually keep our servers synced with the following script, run by cron.
#!/bin/sh
lockfile -r 2 -l 1000 /tmp/synchome.lock || exit 1
rsync -e ssh -avHP --delete zorro01:/home/\* /home >/dev/null
rm -f /tmp/synchome.lock
--

Sometimes my users (including myself) are in a hurry and syncronise files and directories in their homes themselves. This bypasses the lock above and two or more rsync processes are in a race.

What happens is that the competing rsync processes delete each others temporary files a lot of network traffic is wasted since rsyncing fails when the temp file is deleted.

The included patch tries to remedy this situation by reviving the temp file.

Patch (Also to be found at: http://xinit.se/~hes/rsync-2.5.6-revive.patch):
--- receiver.c.orig     2003-01-21 00:32:17.000000000 +0100
+++ receiver.c          2003-10-06 14:30:35.000000000 +0200
@@ -457,13 +457,21 @@
                if (fd1 != -1) {
                        close(fd1);
                }
-               close(fd2);
+
+               /* Revive temp file if someone removed it during receive */
+               fd1 = do_open(fnametmp, O_RDONLY, 0);
+               if (fd1 == -1) {
+                       sprintf(fnametmp, "/proc/self/fd/%d", fd2);
+               } else {
+                       close(fd1);
+               }

                if (verbose > 2)
                        rprintf(FINFO,"renaming %s to %s\n",fnametmp,fname);

                finish_transfer(fname, fnametmp, file);

+               close(fd2);
                cleanup_disable();

                if (!recv_ok) {
--

Hans Eric Sandström
MailCORE AB

ps. A --lock option to mutually exclude updates to the same file from competing rsyncs would be a nice feature. That would sort of obsolete the lockfile trick above.