strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

[tim.conway at philips.com]

I vote for the consistent, complete log format as a solution to this sort 
of thing, and those who need to take non-rsync related actions based on 
what rsync did can write their own applications to do so.

People keep coming up with some particular thing they need done for their 
own application, and want rsync to do that too.  rsync is a tool to make 
one thing exactly like another.  It is not an archiver (keep files 
compressed on the receiving end), a file mover (--move-files), two-way 
syncronizer, nor a distributed filesystem solution.  It makes two things 
the same.  Trying to add unrelated "features" to it just bloats the code 
and takes time away from making it more efficient at what it's supposed to 
do.

"Yeah, our new model car uses gas exponentially with the distance 
traveled, and has to warm up for 1.5 times as long as the trip will take, 
but before we work on that, we want to add the dumptruck, palmpilot, and 
grapefruit spoon features."

Who cares what we parse the log with?  I, for one, DO think perl is a good 
solution.  Text processing was what it was designed for in the first 
place.

Tim Conway
tim.conway at philips.com
303.682.4917 office, 3039210301 cell
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), 
".\n" '
"There are some who call me.... Tim?"