[PATCH] adding two new options to 'cp'
Rick C. Petty
rick-freebsd at kiwi-computer.com
Tue Aug 1 18:20:46 UTC 2006
On Tue, Aug 01, 2006 at 12:51:32PM -0500, Eric Anderson wrote:
> On 08/01/06 12:40, Rick C. Petty wrote:
> It could possibly be bad if you have a real file (say a 10GB file,
> partially filled with zeros - a disk image created with dd for
> instance), and you use cp with something like -spR to recursively copy
> all files. Your destination disk image would then be a sparse file, so
> additional changes and modifications to the file (block allocations)
> would fragment the image and make it slower. That would be unexpected
> and probably go unnoticed for some time. I do see the usefulness in
> this, but I think one needs to be careful to either clearly note in the
> man page that it will make sparse files from *any* file containing a
> string of zeros larger than the block size,
I completely agree. This is why it would not be the default behavior.
Also, gnutar provides this option and it just describes it as "handle
sparse files efficiently"-- so a rewording of that to say that by
"efficient" we mean that the program will allocate as few blocks as
possible in the underlying filesystem. I think a clear description in
the man page would suffice.
> or it needs to 'do the right
> thing' and determine if it's sparse or not.
Unfortunately that would require knowledge which the POSIX calls have no
knowledge of. I don't believe we should roll filesystem-specific knowledge
into cp. However, there is utility in performing a "space-saving" copy,
just as a hardlink is quite space-saving. =)
"-s" or "-S" could refer to sparse, space, squeeze, shrink, or whatever.
-- Rick C. Petty
More information about the freebsd-hackers