Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Aug 2006 12:19:12 -0500
From:      "Rick C. Petty" <rick-freebsd@kiwi-computer.com>
To:        Garance A Drosehn <gad@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: [PATCH] adding two new options to 'cp'
Message-ID:  <20060801171912.GC3413@megan.kiwi-computer.com>
In-Reply-To: <p06230908c0f53813965d@[128.113.24.47]>
References:  <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <ealpn1$lan$1@sea.gmane.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <ean95a$e1u$1@sea.gmane.org> <p06230908c0f53813965d@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060801171912.GC3413>