Re: [Linux-NTFS-Dev] Re: cp --sparse might corrupt DEST

[Szakacsits Szabolcs]

On Mon, 8 Mar 2004, Jim Meyering wrote:
> 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.
> >
> >    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.

Sorry, it wasn't and cp(1) isn't either, I think. Please see below.

> Here it is, in more detail:

Thank you, now I understand your point.
 
> 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.

However I can't really see why it should fail. It's not productive and
IMHO it doesn't follow the rule of least surprise (from pragmatic, not
philosophical POW).

What does cp do if the filesystem doesn't support sparse files? Does it
also detect that scenario and fail? I bet not ;) So why do you want to
introduce an inconsistency?

> 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.  

My cp(1) starts right after listing all options as

     "By default, sparse SOURCE files are detected by a crude heuristic
      and the corresponding DEST file is made sparse as well."

This suggests me, by default using lseek if sparse file detected. 

I also checked what you wrote above and your sentences seem to be true. 
On block devices. But not on ordinary files what cp(1) talks about. No
mention of special handling for block devices in the default case.

        Szaka