Szakacsits Szabolcs <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
