GNU bug report logs - #42034
option to truncate at end or should that be default?

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: option to truncate at end or should that be default?
Date: Wed, 24 Jun 2020 12:56:41 -0700

[Message part 1 (text/plain, inline)]

I allocated a large file of contiguous space (~3.6T), the size of a disk
image I was going to copy into it with 'dd'.  I have the disk image
'overwrite' the existing file, in place using "conv=nocreat,notrunc" (among
other switches) and that works with the final file still using max-sized
8GB extents.

I realize that I _do_ want it to truncate the file to the actual size when
done.

The 'notrunc' switch doesn't work for this purpose as its meaning is
overloaded (it really specifies multiple behaviors) both the non-truncation
effect, as well as a directive to preserve any blocks not written during
that specific invocation of 'dd'.  A possible 3rd behavior arises from a
vague definition of a block.  Do they mean to preserve the data in the
block, or do they mean to preserve the position of the block on disk?  It
seems they mean to preserve data, but whether or not that also preserves a
place on disk isn't specified.

There really needs to be something to specify that writes occur "in-place"
such that no "_RE_-allocation" of blocks occurs (except to extend the file,
if needed)  A second option would be to truncate the file to the last
position written.


Maybe a oflag=overwrite, and a 'ftrunc' for 'final trunc' to the position
of the final byte written?

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.