Using blocklist is a nice idea, maybe you can use it too with cmp to verify the dd-written sectors. I believe dd doesn't do such a check.
I tend to trust dd, but that could be an useful addition as an option, as always with this kind of stuff (including dd) it is always a matter of size of data, using cmp on a bunch of sectors takes no time, but when the number of sectors grows, it may become a time hog.
I hope 'normal' seek will be still possible in next version, not all files will be contiguous (in case of images: can be still loaded with map --mem)
So, you have an image that can be loaded with map --mem, which should be small enough to fit in memory and to be transferred in a reasonable time.
It would make more sense to actually map it in memory, edit it in memory and then dd it back integrally to device after the modifications.
While attempting to make the batch besides (hopefully) working also actually useful, I found another (little or big) issue.
The virtual (or fake) clipboard as it is now (which actually is "the first three quarters of a dd command") can lead to a mess.
When you Cop[Y] a dd command with infile the chosen area of memory is created, then when you Pas[T]e the dd command is completed with the outfile and executed, so it is possible to:
1) [L]oad a file in memory
2) Cop[Y] a part of it
3) [L]oad a completely different file
BUT what will be pasted won't be what was originally selected, but rather the contents of the second loaded file at the address selected on the first file.
So I will have to add a "safety feature" that prevents the use of [L]oad if the (virtual) clipboard is in use, or, if you prefer limit the possibility of Cop[Y] within the same file.
I tried (and it actually seemingly works) to add a "real" clipboard by means of using the memory sector before the first one in use (now that I have prevented the possibility of the program to go before the first address initially loaded this is "safe").
But this clipboard is obviously limited in size to 512 bytes, this allows to Cop[Y] up to 512 bytes (or 1 sector) and being able to [L]oad another file and Pas[T]e it there.
As an example one could quickly load a MBR, Cop[Y] it, then load the initial part of a disk image or the first sectors of a (hdn) and Pas[T]e it.
Question is, what would be a "logical" and "useful" "max size" for this "persistent" clipboard?
Maybe 512 bytes or 1 sector is too little a size, but I don't want to make it too large, as it will write to "memory", I could crc32 a number of sectors before the loaded address and make sure that the checksum is for 00 sectors, and zero out them back on (hopefully) clean exit, but it is not like the program can try a size, find that the memory is not 00, try a smaller size, etc., etc. and without this check there is the risk (if the user selects certain addresses at launch) to "touch" areas that should be left alone.
BTW the same possible issues may happen "forward", i.e. (md)0x300 or 0x60000 may be a too low address to start fiddling with, when loading a largish file/number of sectors.
To be useful on "old" hard disk, the max size could be 63 sectors (or first head), on GPT the canonical 34 sectors could be enough, all in all putting the limit to 100 sectors before (or 51200 bytes) could be enough, about the "forward" what is the lowest address that could be used with no grub4dos data after it?
I initially thought that (on the version I am testing) that the first address with all 00's following it was (md)0x800, but while testing I noticed that this area is already used by grub4dos when dd is used (it is its buffer):
"ADDR and SIZE are used for user-defined buffer. ADDR defaults at 1M, and size default at 64K"
So one could use as default load address 0x800+0x80+0x<max clipboard size>, let's say (md)0x1000=0x200000 for a nice, round number and max_clipboard_size=0x780 sectors or 1920*512=983040 bytes (not nice nor round), or even go a bit higher, like - still say - (md)0x1200=0x240000 and max_clipboard_size=2432*512=1245184, which we could define as "something more than 1 M".
If there was *something* like a (md)nul device for dd one could re-use its buffer as "clipboard", but I think there is no way to dd to a nul device