Re: cp --sparse might corrupt DEST

[Jim Meyering]

Szakacsits Szabolcs <address@hidden> wrote:
> On Mon, 8 Mar 2004, Jim Meyering wrote:
>> Changing cp as you suggest is one way to solve this problem.
>> Another would be to make cp fail when it's asked to do
>> something that doesn't make sense: preserve holes in a
>> non-regular destination file.
>
> I think the later one isn't correct:
>
>    1) it's not cp's job to preserve holes. It's an optimization
>       but it can not be done _always_.
>
>    2) people suppose cp works in the non-regular destination
>       file case. This would get broken with the later change.

Your comments make me wonder if my proposal was clear enough.
Here it is, in more detail:

I will probably change cp so that commands like this fail:

  cp --sparse=always SRC /dev/hda1

That is, if --sparse=always is given and the destination refers to
an existing, non-regular file, then cp will fail.

Note that cp's default behavior (with --sparse=auto, or with no
--sparse=... option) works just fine in that it copies sequences of
zeroes from SRC to the destination rather than trying to use lseek to
create zero-filled holes.  The problem under discussion arises only when
--sparse=always is used and when the destination is a non-regular file
like /dev/hda1.

> BTW, if you're interested in large sparse file handling optimization
> (cp, cat, etc) currently having horrible performance (coredumps, sparse
> matrices, etc) then you might take a look at the relevant part (HANDLING
> LARGE SPARSE FILES) of
>
>       http://linux-ntfs.sourceforge.net/man/ntfsclone.html

As you know, copying sparse files efficiently is not even possible
on many file systems.  If someone submits a clean patch to make
things more efficient for some file system types, I'll be happy
to consider it.