NeoG_ wrote on Yesterday, 22:06:

It's a red herring, dd was set to output progress to the terminal so one of the in-flight progress lines was copied and pasted. The final byte count was as expected
... 1474560 bytes (1.5 MB, 1.4 MiB) copied, 177.923 s, 8.3 kB/s

Weird red-herring - it actually sez "1474560 bytes (1.5 MB) copied" - so under Linux, everywhere a transfer command reports the number of bytes copied... It can't be trusted to be the actual number of bytes transferred? (I'm guessing the "progress lines" were generated, not actually copied from anywhere?)

DaveDDS wrote on Today, 00:29:

NeoG_ wrote on Yesterday, 22:06:

It's a red herring, dd was set to output progress to the terminal so one of the in-flight progress lines was copied and pasted. The final byte count was as expected
... 1474560 bytes (1.5 MB, 1.4 MiB) copied, 177.923 s, 8.3 kB/s

Weird red-herring - it actually sez "1474560 bytes (1.5 MB) copied" - so under Linux, everywhere a transfer command reports the number of bytes copied... It can't be trusted to be the actual number of bytes transferred? (I'm guessing the "progress lines" were generated, not actually copied from anywhere?)

Not strange, OP had status=progress flag set which is what created the partially copied line. The flag continually writes the block count/speed/time to the terminal so you can track the progress of the command. Anything before the in/out block totals is a progress status line and is not a final count. It's not a red herring as in dd is mis-reporting the block count. It's a red herring as in you are focusing on a line that is akin to saying "98% copied" and not the final byte count.

Just in case anyone is interested (I'm thinking of making this for myself anyway)

I've been thinking about how to reliably write disk images from an "unknown" system, and I've come up with this:

-Your system has be capable of booting from optical media (CD or DVD)!

I can place all the DOS images I have (at the moment with the new ones from "allbootdisk" it's >25) on a CD, and make that CD bootable with the ImageDisk stand-alone floppy boot.

This boot makes a RamDisk for working storage, has some basic network file transfer ability, and can "see" the DVD it was booted from (so it could access many images without having to transfer them) - and of course has ImageDisk and a number of usefull tools.

Unfortunately the method I used to make a .ISO bootable works by "faking" the floppy to BIOS - so tools like my XDISK (which goes through BIOS) can't work because they wouldn't see the actual floppy.

But... ImageDisk doesn't use BIOS - it "talks" directly to the floppy controller hardware. So... it CAN read/write actual floppy disks even when booted from optical media.

Most DOS boot floppies are simple .IMGs which are raw sector dumps of the DOS formats. ImageDisk being able to handle all kinds of floppy formats (incl non-DOS ones) needs a .IMD which contains records describing the format for each track.

But ... I have a utility "BIN2IMD" which can convert a raw binary dump (like a .IMG) into a full .IMD - You have to tell it things like cylinders, sides, sectors/track, sector size and Interleave to do the conversion - I can provide a .BAT file able to easily converting the common DOS floppy formats (which you can tell by size)

This gives you a CD which you can boot and create any DOS boot disk in the collection.
It would however require and actual physical floppy (with standard PCish Nec765 family compatible floppy controller chip)

Just some thoughts - if anyone is interested I can put it together.

NeoG_ wrote on Today, 00:34:

Not strange, OP had status=progress flag set which is what created the partially copied line. The flag continually writes the block count/speed/time to the terminal so you can track the progress of the command. Anything before the in/out block totals is a progress status line and is not a final count. It's not a red herring as in dd is mis-reporting the block count. It's a red herring as in you are focusing on a line that is akin to saying "98% copied" and not the final byte count.

Fair enough - it seems a fundamentally different way of thinking. When I create a bit of software that continually reports it's progress (perhaps by overwriting a single line on the TTY screen), I always make sure to issue that line at the very end of the operation - so the reported progress is up to date and there's no "partial" progress left on the screen.

Easy enough to do ..

1if (report_progress == ON):
2   report status with "<return>status text" a it updates ... *1
3   output <return> after all processing but before final results are displayed. *1
4   (If you want to avoid redirection - output these to stderr)
5Always:
6  For final results, output "status text<newline>" first *2
7  Report anything else to be in final report.

*1 Technically you could simplify this to just outputting "status information<return>" ... but I generally don't like the cursor to be sitting at the start of a printed line during operation.

*2 As "bytes transferred" only goes up ... the final message it always going to fully overwrite any partial progress which might be on the TTY screen.

And yeah, this is getting off-topic, lets just say it's a matter of preference and leave it at that!

DaveDDS wrote on Today, 00:57:

Unfortunately the method I used to make a .ISO bootable works by "faking" the floppy to BIOS - so tools like my XDISK (which goes through BIOS) can't work because they wouldn't see the actual floppy.

I've seen BIOSes demote the real floppy drive to B: in that situation. What happens if you have two floppy drives? No idea, perhaps that wasn't considered since it would be pretty niche once CD-ROM booting went mainstream.

DaveDDS wrote on Today, 01:31:

Fair enough - it seems a fundamentally different way of thinking. When I create a bit of software that continually reports it's progress (perhaps by overwriting a single line on the TTY screen), I always make sure to issue that line at the very end of the operation - so the reported progress is up to date and there's no "partial" progress left on the screen.

dd probably does this too, it's just that an errant keypress while dd is running could be echoed to the screen and cause you to get an extra line or extra status report like that, while on DOS, such keypresses are buffered and don't get looked at until after the program is done.

jakethompson1 wrote on Today, 01:37:

I've seen BIOSes demote the real floppy drive to B:

I've had systems which did and ones which didn't

Like so many "improvments" - not something you can trust to be there!

jakethompson1 wrote on Today, 01:38:

... while on DOS, such keypresses are buffered and don't get looked at until after the program is done.

When I write something that takes long enough to want ongoing status output - I typically check from time to time for an "abort" key (often Esc) to abort gracefully and ignores anything else. (but of course depends on what key interrupts are supported by OS it's .running under)

In Unix, that would be handled by the shell - e.g. control+c and control+z are intercepted by the shell and handled outside of the application which is running, either pausing it (and allowing for the paused process to be either backgrounded or resumed again) or stopping it.

You can have the application handle character input itself (think SDL applications, or something like vi or nano which captures control codes itself), but it's not the standard Unix way for most utilities ran in the terminal.

megatron-uk wrote on Today, 06:56:

In Unix, that would be handled by the shell ....

Agreed (I suspected these comments would generate "feedback" 😀 )

When I'm developing under a "real" OS - I usually don't bother with handling these things unless there is a reason the particular program should shut-down "gracefully".

I also don't fret-over/half-expect that when a program is forcefully aborted, there may be "droppings" on the screen which may not reflect absolute reality at the time of said forced termination.

What I dislike is programs that complete normally and leave inaccurate information on the screen - I do tend to go out of my way to avoid that.

When I play with BeOS, I use "signal(SIGINT, handle_sigint);".
Because the default keys are Alt + C instead of Control + C, and you can spend some time trying to understand why an app launched from terminal doesn't want to close 😀