On Tue, Jun 12, 2007 at 04:41:25PM +0100, Daniel P. Berrange wrote:
> Urm, the 'truncate' function is only valid for making files *smaller*.
man 3 truncate:
If the file previously was larger than this size, the extra data is
lost. If the file previously was shorter, it is extended, and the
extended part reads as null bytes (’\0’).
> Check the docs, in particular the last line....
As far as POSIX is concerned, it extends the file. That may not be true
for some other systems, but this wasn't the case. Also, the Single Unix
Specification says about extending:
XSI-conformant systems shall increase the size of the file
The functionality described is an XSI extension. Functionality marked
XSI is also an extension to the ISO C standard. Application writers may
confidently make use of an extension on all systems supporting the
X/Open System Interfaces Extension.
> What you actually want to do to reliably grow a file while preserving its
> data is to 'seek' to the larger size. There's no need to use Perl - dd
> is happy doing it
seek after the end and write should be semantically equivalent to
truncating after the end. I don't think seek after the end plus write is
more reliable than a truncate as far as number of supporting systems,
but I may be wrong.
> dd if=/dev/zero of=file.img bs=1 count=0 seek=8G
Great. That's a truncate: strace ...
open("file.img", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 1
ftruncate64(1, 8589934592) = 0
But count=0 is new to me, I always used at least count=1 (and
conv=notrunc) and didn't like the extra byte at the end. Then I switched
to perl for those cases. Thanks.
--
lfr
0/0
pgpMVC08198Ac.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home