bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp command - problem with sparse


From: Jim Meyering
Subject: Re: cp command - problem with sparse
Date: Thu, 03 Feb 2005 09:52:14 +0100

Eric Blake <address@hidden> wrote:
> According to James Youngman on 2/1/2005 3:17 AM:
>>
>> Unix systems automatically generate sparse files when programs seek
>> forwards on their output file.  There is no need to have a "sparse"
>> attribute.  This is what coreutils' "cp" does.
>
> Right now, the tests/du/8gb test uses dd to try to create a sparse file;
> and strace'ing that on cygwin shows that it uses just lseek() followed by
> ftruncate() (no intervening write()).  But the code in src/copy.c goes to
> great lengths to write() before calling ftruncate(), with the comment that
>  "the kernel would truncate the file at the end of the last write
> operation".  Which is it?  Is copy doing more work than it should, or
> should dd also be doing a write before truncate?  POSIX does say that
> ftruncate shall increase the size of the file in XSI systems, but allows
> it return an error and keep the size unchanged on non-XSI systems.

Well, to make that test case stop skipping on cygwin, we could
apply the band-aid of simply using cp --sparse=always to
copy the dd-created file.

I'm reluctant to modify dd solely to accommodate Cygwin
when it may be jumping on the XSI bandwagon soon anyhow,
but if the change is not too ugly, I'll consider it.

> I ask, because at the moment, cygwin's implementation only makes a sparse
> file on write() after lseek(), although the developers are considering
> making ftruncate() after lseek() also create a sparse file.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]