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