ownership error while running an ubuntu mirror site?

[Carlos Carvalho]

Mauricio Tavares (raubvogel at gmail.com) wrote on 9 August 2010 06:59:
 >On Mon, Aug 9, 2010 at 4:07 AM, Jonathan Davies
 ><jonathan.davies at canonical.com> wrote:
 >> On 07/08/10 23:02, Mauricio Tavares wrote:
 >>> I looked in the log file further up and found the following entry:
 >>>
 >>> pool/main/g/glew/
 >>> pool/main/g/glib1.2/
 >>> pool/main/g/glib2.0/rsync: send_files failed to open
 >>> "/pool/main/g/glib2.0/libglib2.0-0_2.25.12-1ubuntu1_i386.deb" (in
 >>> ubuntu): Permission denied (13)
 >>> pool/main/g/glibc-doc-reference/
 >>> pool/main/g/glibc/
 >>> pool/main/g/glibmm2.4/
 >>>
 >>> Why wouldn't it be able to write to that directory? As mentioned
 >>> before, that entire directory path is owned by www-data:www-data. Am I
 >>> missing something here?
 >>
 >> This Maverick package was blacklisted as it broke people's desktops on i386:
 >>
 >> - https://bugs.launchpad.net/bugs/614240
 >>
 >      Thanks for that bit of info. Now the followup question is: if
 >that is the case, why did it take 2 days and 9 rsync runs (I am using
 >ubumirror, so it is called by ubuarchive) for it to stop sending the
 >error message? I thought that when running rsync, if you tell it to
 >match the source and a file is deleted in the source, the next time
 >rsync is run it would delete in the target and be over with it.
 >Instead, only in the 10th rsync run the offending file is actually
 >deleted
 >
 >deleting pool/main/g/glib2.0/libglib2.0-0-dbg_2.25.12-1ubuntu1_i386.deb
 >
 >I looked at the ubuarchive script, and its rsync command seems to want
 >to do what I would expect:
 >
 >rsync -av --timeout=600 --partial --delete --delete-after \
 >      --bwlimit=$SPEED \
 >      --exclude "indices/" --exclude "dists/" --exclude
 >"project/trace/${HOSTNAME}" \
 >      --exclude "Archive-Update-in-Progress-${HOSTNAME}" \
 >      $UBUARC_EXCLUDE \
 >      $UBUARC_MIRROR $UBUARC_DIR
 >
 >I am not going to claim I am a rsync expert, but the only thing I can
 >think of is that --delete-after was somehow annoyed, but files are
 >being added and deleted without any issues; only this specific package
 >was acting up and causing all this trouble.

The problem with this one is that it was not deleted upstream; only
its permissions were changed. The error is not in writing to the
directory, it's in the origin.

When there's an error in the origin rsync doesn't remove files in the
destination by default. If the problem disappeared is because either
the permissions were changed or the file was removed.