bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

on "dd" using "seek" vs. "read" & >32-bit sizes


From: Linda Walsh
Subject: on "dd" using "seek" vs. "read" & >32-bit sizes
Date: Thu, 15 Dec 2005 16:26:51 -0800
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Sometimes I would like "dd" to copy the contents of "Random-Block-Object-A"
to "Random-Block-Object-B", starting from the middle of of the file.

I can specify the "seek=BLOCKS" param, but it appears that "dd" doesn't
translate this to a "seek" command but instead uses "read" to to
sequentially access the block device.  Is this the case or am I
hallucinating?

If I am not hallucinating, I can see this being done by design
from a historical perspective, working with tapes or such, but I'm
not sure it makes as much sense today.  Perhaps an attempt at an lseek
on an "OS", and if that fails, then failover to the older "read" behavior?

If it is deemed necessary, maybe some flag to force old behavior?

It gets painful when copying multi-gigabyte images where one may have
already copied previous parts of an image.

Second question I had -- at times, it seems like various utils
are limited to 2G file offsets on OS's (i686-linux, i686-cygwin)
that support files >2G.  Is this "old" behavior that will (should?)
be disappearing?  I'd noticed it before in specifying counts
and such in "dd" (among others).

Thanks,
Linda






reply via email to

[Prev in Thread] Current Thread [Next in Thread]