Follow-up Comment #8, sr #107341 (project administration):
> chmod -r a+rwX
Maybe not -w ;)
I cron'd this:
cd /srv/download && (find -type d -print0 | xargs -r -0 chmod 2775) && (find
-type f -print0 | xargs -r -0 chmod 664)
It only needs a few seconds to complete.
I chose not to mess with sy
Follow-up Comment #7, sr #107341 (project administration):
it is true that we used to recommend --ignore-errors. But I noticed
yesterday that the rsync documentation says this about it:
> Tells --delete to go ahead and delete files even when there are I/O
errors.
That does not seem like a goo
Follow-up Comment #6, sr #107341 (project administration):
> I thought maintainers intentionally were given the power to
> change permissions in their release area. Not that I have a
> problem myself with making them all readable.
A few months ago I ran some 'find' to check what kind of permissi
Follow-up Comment #5, sr #107341 (project administration):
Yeah, I realized too late I was completely off-base with the -noredirect. I
fixed http://www.gnu.org/server/mirror.html.
I can contact all the mirror maintainers (or at least the ones with stale
files), but first I want to be sure about
Follow-up Comment #4, sr #107341 (project administration):
For clarity: rsync://dl.sv.gnu.org/releases-noredirect is invalid, so the
documentation needs to be fixed back.
The big job is contacting the early mirror maintainers so they update their
scripts.
Also,
"There will probably be some perm