7 ms·
I honestly don't know with certainty. I explicitly set drive types with "SET RA* TYPE=" (and RQ*) and image sizes with RAUSER, and suspect that the metadata got
by johnklos 3y ago
I honestly don't know with certainty. I explicitly set drive types with "SET RA* TYPE=" (and RQ*) and image sizes with RAUSER, and suspect that the metadata got written to after the drive type's size offset in to the image.
I noticed several other bugs: one of my disk images has the metadata block at the beginning of the image (no idea how). One of my systems (a big endian system - imagine Mark's shock and surprise when he learns that people who run less common systems in simh sometimes run... less common systems!) had appended an extra metadata block onto each image every time simh was relaunched.
Once I realized that there were these blocks of extraneous data here and there, I started looking online to see if others had similar experiences, and came across the threads talking about this new "feature".
And I disagree that writing disk images to disks / partitions without explicitly giving dd the size isn't a typical use case. I can't remember the last time I specified the size. The size of the file is always assumed to be the size of the write, and it'd be a very special edge case to deliver a file, then tell people to only write a specific size. Go download any .iso or .img file for installing any OS out there, and show me on the download page where we're told to stop after a certain byte (block) count if you disagree.
- mlyle 3y ago> I started looking online to see if others had similar experiences, and came across the threads talking about this new "feature". OK, then it sounds like you have a legitimate bug: a far clearer report than anyone else has provided here. Perhaps you should communicate it. > And I disagree that writing disk images to disks / partitions without explicitly giving dd the size isn't a typical use case. ' I didn't say that. I just said (in other comments) that if you overrun the size of the device or partition, the kernel reports an error and then dd whines that it couldn't write the last bit. $ sudo dd if=/dev/urandom bs=512 of=/dev/fd0 dd: error writing '/dev/fd0': No space left on device 2881+0 records in 2880+0 records out 1474560 bytes (1.5 MB, 1.4 MiB) copied The only person in the issue with data loss is the reporter, who was dding image files onto offsets on an unformatted SD card. When one of them got longer, it created problems-- overwriting the first bit of the next image. If you're doing something like that, you really ought to be providing the size.