Re: cp --sparse might corrupt DEST

[Jim Meyering]

Szakacsits Szabolcs <address@hidden> wrote:
>> > This is what I thought would be unreliable:
>> >
>> > cp --sparse=always sparse-image-file.img /dev/hda1
...
> Actually it's a bug in cp. What's cp job? To copy files reliable. Can it
> do that when used in the above case (block device as the destination)? No.
>
> Sure it's a bug. If cp detects sparseness in the source file it will skip
> on the destination file and leave the skipped data unchanged. Source and
> destination won't be the same. It wasn't a copy operation. cp should fill
> those skipped areas with zeros, well actually never skip in these cases.
>
> cp should check the file type of the destination and if it's block device
> then fallback to --sparse=never.

Thank you for the report.
Did you actually run a command like this?

  cp --sparse=always sparse-image-file.img /dev/hda1

Did it produce any diagnostic?  On what OS?
I did the following on a linux-2.6.2 system:

  # dd bs=1 seek=100k of=a < /dev/null
  # cp --sparse=always a /dev/fd0
  cp: writing `/dev/fd0': Invalid argument
  [Exit 1]

The diagnostic was due to a failing ftruncate.

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'll think it over...