bug in rsnapshot 1.2.1 due to change in /bin/cp 5.93

[Tim Ruddick]

I recently installed Fedora Core 5 on a machine and downloaded the
rsnapshot RPM (v1.2.1) from the Downloads section of www.rsnapshot.org.

FC5 uses /bin/cp version 5.93, and this version doesn't like a trailing
slash on the destination directory name.  /bin/cp v5.2.1 (the version on
Fedora Core 3) used to accept it.  Looking at the man page, it appears
version 5.93 can be made to use the old behavior by passing '-T' on the
command line.  Vexingly, v5.2.1 doesn't like the -T option.  Examples:

 (cp 5.2.1)
    # mkdir -p x/y

    # cp -alv x/ z/
    `x/' -> `z/'
    `x/y' -> `z/y'

    # cp -alv -T x/ z/
    cp: invalid option -- T

 (cp 5.93)
    # mkdir -p x/y

    # cp -alv x/ z/
    cp: target `z/' is not a directory: No such file or directory

    # cp -alv -T x/ z/
    `x/' -> `z/'
    `x/y' -> `z/y'

When I try to run a backup now using rsnapshot, I get the following message:

 /bin/cp: target `/mnt/backup/snap/hourly.1/' is not a directory: No such file 
or directory
 ----------------------------------------------------------------------------
 rsnapshot encountered an error! The program was invoked with these options:
 /usr/bin/rsnapshot hourly 
 ----------------------------------------------------------------------------
 ERROR: /bin/cp failed. Perhaps this is not GNU cp?
 ERROR: Error! cp_al("/mnt/backup/snap/hourly.0/", "/mnt/backup/snap/hourly.1/")

I looked at the rsnapshot CVS repository to see whether a newer version
(rsnapshot 1.2.3) might have already addressed this, but it looks like it
also puts a trailing slash on the destination directory name and doesn't
know about the '-T' option.

In the meantime, I'm working around this by configuring rsnapshot to use
rsync instead of /bin/cp to do the initial tree copy.  So far, that appears
to be working.

This is a bit of an edge-case in the /bin/cp argument syntax, but it is
certainly a change; it might have broken more than just rsnapshot.  I'm
CC'ing the GNU coreutils bug list, in case they're interested.

Tim.

P.S. Here's a sleazy test that checks whether /bin/cp accepts the -T option

 (cp 5.2.1)
   # /bin/cp -T /bin/cp /dev/null 2> /dev/null
   # echo $?
   1
 
 (cp 5.93)
   # /bin/cp -T /bin/cp /dev/null 2> /dev/null
   # echo $?
   0