[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cp --sparse might corrupt DEST
From: |
Jim Meyering |
Subject: |
Re: cp --sparse might corrupt DEST |
Date: |
Mon, 08 Mar 2004 15:53:14 +0100 |
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.