4 ms·

This is decidedly not the case, and it attempts to misattribute the issue. I cared because it happened to me. Like most people, I use a package management syst

This is decidedly not the case, and it attempts to misattribute the issue. I cared because it happened to me. Like most people, I use a package management system (pkgsrc), so I wasn't on the simh mailing list and I didn't know about this change. I update simh via pkgsrc, tried to restart some virtual machines and had fscks corrupt the filesystems of those VMs. I went looking in the mailing lists, saw the discussions, saw how people asked nicely for him to do something more reasonable (the most reasonable would be to not default the feature to on), and saw how he simply doubled down and became dismissive. Note that I don't advocate for harassing people at all. That's a separate issue, and I condemn anyone who'd encourage harassment. "Metadata is a whole lot less useful if it's off-by-default." You're making excuses for him. We shouldn't force something on others because of specious suggestions that it might be useful in the future, particularly when it's actively harmful right now.

mlyle 3y ago
How does fsck corrupt filesystems when the metadata is something that's post-pended past the end of the image? The reason why the original user (al20878) in the issue had a problem was because they were storing the images without a filesystem and expected them to have never changed size when they copied the image to the SD card. This isn't a typical use case. Can you explain how you ended up with corruption based on a small thing being postpended to a raw disk image?
- 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.

mlyle 3y ago

How does fsck corrupt filesystems when the metadata is something that's post-pended past the end of the image? The reason why the original user (al20878) in the issue had a problem was because they were storing the images without a filesystem and expected them to have never changed size when they copied the image to the SD card. This isn't a typical use case. Can you explain how you ended up with corruption based on a small thing being postpended to a raw disk image?

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.