[PATCH] adding two new options to 'cp'

[Rick C. Petty]

On Tue, Aug 01, 2006 at 01:06:55PM -0400, Garance A Drosehn wrote:
> 
> The point is not that you need an explicit switch, the
> point is that you have to add a lot of code to 'cp' for
> 'cp' to do the job correctly.

Not really.  See my example in a previous post.  All you need to do is
perform an lseek(2) instead of a write(2) if the block you read is all
zero.

> You are changing the nature of how the command works.

No, you're adding features, not changing the behavior for the default
case.

> I very much doubt you
> can implement that *correctly* in a mere 160 bytes of
> additional object code!

I'd be willing to bet that my aforementioned example would fit in that
space-- because you already do an fstat & the read/write code-- the
only thing to add is the zero-checking and seek ahead code.

> -r-xr-xr-x  1 root  wheel  15348  [date]  /bin/cp
> -r-xr-xr-x  2 root  wheel  44288  [date]  /sbin/dump
> -r-xr-xr-x  2 root  wheel  58736  [date]  /sbin/restore

dump/restore is significantly different in operation than cp.  Both do
a lot more than just copy files.  Also dump/restore is specific to UFS
and my example code would handle sparse files for any filesystem.

> I realize a lot of these decisions are somewhat subjective.
> "One person's feature is another person's bloat".  But in
> the case of this specific example, I (personally) would
> not want 'cp' to implement every detail which is already
> handled by dump/restore.

I don't think this is what people are asking for.  BTW, does dump/restore
handle extended attributes?  Last I checked, it didn't.  But then again I
don't think cp or tar do either.  Feel free to enlighten me.

-- Rick C. Petty