Re: cp command - problem with sparse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAaOB84KuGfSFAYARAoXxAJ9nbKLwI8fGcdAJ9vVggGwehujbFwCgnIuv kmBzebHsRNu4iHb7q1vPGE0= =Wpzz -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
Eric Blake [EMAIL PROTECTED] 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Documentation change for 'echo' man pages
In the 'man' docmumention of 'echo', there is the line:- With -e, the following sequences are recognized and interpolated: It should read 'interpreted' not 'interpolated'. Thanks, Karim ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Documentation change for 'echo' man pages
Karim Rashad [EMAIL PROTECTED] writes: With -e, the following sequences are recognized and interpolated: It should read 'interpreted' not 'interpolated'. Thanks. That problem is fixed in the current version of coreutils, which you can find here: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
