On 19 Aug 2003, Peter Peltonen wrote:
> you can see that nothing changed :(
>
> And it seems to be always the same files that are "uptodate" and that
> are not...
If it (as I already suggested) is something that is taking place on the
server side and is beyond your control, then nothing you do will fix it.
I do have one last suggestion, though. rsync documents that the -vvv,
-vvvv and higher options are only "useful for debugging rsync". That is
usually a diplomatic way of saying that they will flood you with detail
on what is being transferred and why. In a LOT of detail. Perhaps in
enough detail to reveal why each file is marked as it is and what
actions rsync actually takes (since it clearly is not actually
transferring the files anyway).
So give it a shot, perhaps on a limited subset of the whole image and
leaving a whole lot of room for the output (it generates perhaps thirty
or forty lines of text per file, including every step taken to decide
whether or not to update I think). Maybe it will be enough to help
figure it out further.
rgb
>
> For reference, here is the RH62 script I used:
>
> --<snip>--
> #!/bin/bash
>
> MIRRORDIR=/scratch/mirror
> VERBOSE=1
>
> MIRROR=ftp.funet.fi
>
> REMOTE="$MIRROR::ftp/pub/mirrors/ftp.redhat.com/pub/redhat/linux/updates/6.2/en/os/"
> LOCAL="$MIRRORDIR/redhat/linux/updates/6.2/en/os/"
>
> if [ ! -z $VERBOSE ]; then
> VRB="-vv --stats"
> fi
>
> echo "Fetching RH62 updates at `date`."
> rsync $VRB -a --exclude "SRPMS" --exclude "alpha" --exclude "sparc*" \
> --delete $REMOTE $LOCAL
> echo "Fetched RH62 updates at `date`."
> echo " "
> --</snip>--
>
> Regards,
>
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
