[patch] read-devices

[jw schultz]

On Fri, Aug 30, 2002 at 02:49:21PM -0500, Dave Dykstra wrote:
> Oh, syncing from a pipe on one end to a file on the other end is a
> different story.  That I can see a use for.  However, it's not really what
> the rsync command is designed for; it's designed for handling lots of
> files.  I would think a simple tool based on librsync would be better
> suited.  If we did want rsync to support it, I wouldn't lump it with
> reading of other device files.  A syntax of specifying "-" as the source
> file would make some sense, but a whole lot of options (especially most of
> the ones inferred by "-a") won't make any sense in that situation, and the
> destination has to be a file and cannot be a directory.  I think it would
> probably have too great of an impact on the rsync code to be worth
> supporting.
> 
> Syncing an entire raw partition is not a good idea unless you plan to have
> it unmounted during the entire operation, because otherwise you're likely
> to get some corruption in the copy.

Librsync for stdin or for seekable devices makes some sense.

I can see the possible use for doing a disk volume in the
case of database tablespaces.  In that particular case i
would be inclined to use something aware of the database block size 
and that would update in-place instead of merging changes
with an original.  Databases don't move the data around so
block relocation isn't an issue.

In both instances Contorting the rsync utility is ill
advised.

(more below)

> 
> On Fri, Aug 30, 2002 at 02:48:20PM +0300, Eran Tromer wrote:
[snip jw]
> > 1. To get permissions and special files right, I had to run the receiver 
> > side as root. From a security viewpoint, this is already nasty in the 

Lock down the backup machine and pull from the server as a
non-root user that has read permissions.  

> > extreme, but it's much worse than that, because now the backup machine 
> > contained all sort of spooky device files and suid root binaries and 
> > whatnot, created by rsync. If the server was compromised, in all 
> > likelyhood the backup machine would go down next. Trusting permissions 
> > on the parent directory of the rsync destination directory is not quite 
> > enough for such stuff -- these things *have* been bypassed before.

Mount -o noexec,nodev

[snip jw]
> > Last but not least: this is the Unix way. It provides much power and 
> > flexibility to the user, hence it is a Good Thing. I find my local 
> > patched rsync very useful, and would experience eternal merriment if 
> > everybody got that feature.

<religion>
No.  It isn't the UNIX(TM) way.  It it were, UNIX would look
like DOS.  The UNIX Way is to have a plethora of small
utilities that each perform one generalized task and perform
it well within a framework that allows combining these
utilities together in complex and unanticipated ways.  UNIX
is not a toolbelt with an assortment of Swiss army knives
and crescent wrenches, it is a toolsheed filled with
specialized tools and an autolathe to create any new tools
you can dream up.  It is this multiple tool flexibilty that
gives the user so much power.

Librsync goes part of the way towards this kind of
flexibility.  You can use librsync to create specialized
tools to meet unique needs.
</religion>

That all said, i can _almost_ see allowing a --copy-block
except that would be to device files what --copy-links is to
symlinks.  However, the frequency with which one one run
this on a directory of device files is too low to be worth
the pollution in my opinion. 

The two top measures that i use in evaluating an
enhancement are consistancy with existing usage or
the 10-words-or-less synopsis, and the scope of code change.
Your change is inconsistant with "syncronize fileS and directory trees".  
A simple --copy-block might not be to much change
if the file-size determination can be done simply as an
follow-on to stat().  Final determination would be by the
maintainers and i doubt they would go for it.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt