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 exten
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, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely
close 41657
thanks
No one else has commented therefore I am closing the bug ticket. But
the discussion may continue here.
Michael Coleman wrote:
> Thanks very much for your prompt reply. Certainly, if this is
> documented behavior, it's not a bug. I would have never thought to
> check the docu
close 41792
thanks
Since the discussion has moved away from anything GNU Coreutils
related and doesn't seem to be reporting any bugs in any of the
utilities I am going to close the bug ticket. But discussion may
continue here regardless. If we see a dd bug we can re-open the
ticket.
Ricky Tigg
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 s
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
wrote:
> On Jun 24 2020, L A Walsh wrote:
>
> > A second option would be