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

Previous Next

Package: coreutils;

Reported by: L A Walsh <coreutils <at> tlinx.org>

Date: Wed, 24 Jun 2020 19:57:01 UTC

Severity: normal

To reply to this bug, email your comments to 42034 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#42034; Package coreutils. (Wed, 24 Jun 2020 19:57:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to L A Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 24 Jun 2020 19:57:01 GMT) Full text and rfc822 format available.

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)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#42034; Package coreutils. (Wed, 24 Jun 2020 20:08:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 42034 <at> debbugs.gnu.org
Subject: Re: bug#42034: option to truncate at end or should that be default?
Date: Wed, 24 Jun 2020 22:07:23 +0200
On Jun 24 2020, L A Walsh wrote:

> A second option would be to truncate the file to the last position
> written.

$ truncate -r $src $dest

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-coreutils <at> gnu.org:
bug#42034; Package coreutils. (Wed, 24 Jun 2020 22:31:01 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: 42034 <at> debbugs.gnu.org
Subject: Re: bug#42034: option to truncate at end or should that be default?
Date: Wed, 24 Jun 2020 16:30:18 -0600
L A Walsh wrote:
> 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 ...

It's possible that you might want to be rescuing data from a failing
disk or doing other surgery upon it.  Therefore I want to mention
ddrescue here.

  https://www.gnu.org/software/ddrescue/

Of course it all depends upon the use case but ddrescue is a good tool
to have in the toolbox.  It might be just the right tool.

Take for example a RAID1 image on two failing drives that should be
identical but both are reporting errors.  If the failures do not
overlap then ddrescue can be used to merge the successful reads from
those two images producing one fully correct image.

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#42034; Package coreutils. (Thu, 25 Jun 2020 00:10:01 GMT) Full text and rfc822 format available.

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 42034 <at> debbugs.gnu.org
Subject: Re: bug#42034: option to truncate at end or should that be default?
Date: Wed, 24 Jun 2020 17:09:30 -0700
[Message part 1 (text/plain, inline)]
I think that would work in my specific use case.
I can think of other use cases that it probably wouldn't, but I'm not going
to worry
about those right now.  :-)

Thanks!
-l




On Wed, Jun 24, 2020 at 1:07 PM Andreas Schwab <schwab <at> linux-m68k.org>
wrote:

> On Jun 24 2020, L A Walsh wrote:
>
> > A second option would be to truncate the file to the last position
> > written.
>
> $ truncate -r $src $dest
>
> Andreas.
>
> --
> Andreas Schwab, schwab <at> linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 359 days ago.

Previous Next


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