This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Wrong file position after writing 65537 bytes to block device

On 18.12.2017 16:27, Steven Penny wrote:
On Mon, 18 Dec 2017 14:10:35, Corinna Vinschen wrote:
In general, the writes on disk devices is sector-oriented.  Howewver,
in this case ftell should have returned 65536.  The problem here is
that the newlib implmentation of ftell/ftello performs an fflush
when called on a write stream since about 2008 to adjust for appending
streams.  Given your example (thanks for the testcase!) this seems
pretty wrong.  Looking further it turns out that neither glibc nor BSD
actually calls fflush in this case.  There's only a special case for
appending streams, but this calls lseek, not fflush.

Looks like a patch is required.  Stay tuned.

is it though? he says "write 65536 + 1 bytes", but as far as i can tell, you
cant do that. quoting myself:

Seeking, reading and writing must all be done in multiples of sector size, in
my case 512 bytes

so it would make sense that the position becomes "65536 + 512"

You can do that on a "block" device. It's "raw" devices that have
transfer unit restrictions.

A block device creates an abstraction over a disk, dividing it into
blocks. Those blocks are not related to the underlying sector size;
they could be larger (e.g. 4096 byte block size, versus 512 byte
sectors) or even smaller (e.g. 4096 byte block size, versus 65536
byte flash erase block size).

Unix block devices let you read, write and seek using byte offsets
and sizes.  The bytes which are affected by a write operation map
to one or more ranges in one or more blocks. All of the blocks have to
be read into memory (if they aren't already). The bytes are updated,
and then the blocks are marked dirty and written out (eventually).
More changes can take place before that happens.

So for instance if we have a block device (4096 bytes) over a flash
device with 64 kB erase blocks, we can write just one byte somewhere
in a block. When this change is flushed, the entire erase block has to
be erased and rewritten.

Because of the abstract nature of block devices, it's largely
pointless to use the "dd" utility; you can use "cp" to copy them.
"dd" is required when you need to control the exact size of the
read and write calls. Thus "cat /dev/zero > /dev/blockdevice"
has the same effect as "dd if=/dev/zero of=/dev/blockdevice".

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]