Hmmm.
You seemingly tried to extract an amount of 1073741824 bytes out of a file that only contains 5120 of them
dd as I noted earlier is a "strange" tool, on one side it is very exact (and potentially "dangerous"), on the other it allows - autocorrecting them - some "user errors".
If PC's had a robotic arm , I would personally implement an "aggressive" interface, which would slap the user in the face shouting "are you §@ç#ing crazy?"
If you had attempted to write that dd command through the idd.g4b you should have gotten a warning that you were trying to transfer more bytes than the infile contains.
Of course it is not a problem to check that "amount" does not exceed infile size (and "correct" the data in verifydd.g4b), will do .
About the 1+1, approach, the issues are twofold:
1) it is "ugly" <- but once said that, who cares, if it works, it works in war and love and grub4dos scripting everything is fair
2) it won't work with fragmented files and as such it is only good for contiguous blocklists (in practice it is a good thing, as it will cover all the 11xxx cases different from the two already covered by :begins11 , i.e. 11210:11221 and 11110:11122
#test to see if quick verify is possible
if %flags:~-3,3%==222 call :ends222 &; goto :eof
checkrange 11210:11221 calc %flags% && call :begins11 &; goto :eof
checkrange 11110:11122 calc %flags% && call :begins11 &; goto :eof
#only first three cases above actually working in a different way
#the other ones are all together in the (rd) approach
Some comments from the version of verifydd.g4b I am currently working on, this is the subroutine that is called if there is a 55AA at offest 510 in the first sector of the file/blocklist:
:ends55AA
#if we are here there are two possibilities:
#1) either both infile and outfile are a (single) blocklist
#2) at least one of the two is a file (fragmented)
#let's make the easier case #1 above, flags must be 11xxx
checkrange 11 calc %flags% / 1000 && echo flags is 11xxx
#now if flags is 11xxx we can use the +1, trick by deomsh
#we need to find a sector - any sector - on the same device where the file/blocklist resides
#that has NOT 55AA at the end, we try first following sectors (if any) and then we look on following sectors on the device
#we re-use the chblocks subroutine to get the device, blocks start and blocks length from current blocklists
## it is a rare-rare case, but what happens if infile or outfile are the last sector of a device?
I found after mapping to (rd), rd_base can be set higher and rd_size can be set lower, without the (remaining) content of (rd)+1 is changed.
You are under-selling yourself.
You are telling me that::
the (rd) mapping can be considered a resizable sliding window on the contents of the (md) device with single byte resolution.
Now it sounds a lot more professional.
And yes, it should work just fine and be much faster than the Fn.42 piping into crc32 .
Still the problem with fragmented files remain, I know that the list of blocklist works, but it works - more or less - as long as the amount of bytes in the blocklist command does not exceed this (or that) limit, since we are now using a "blocklist %infile% | set ifblocks=" the limit is currently grub4dos variable size, this could be worked around writing to a (temporary) memory area *like* "blocklist %infile% > (md)0x60000+1" and then parse it with cat, but is there a limit in the size of parameters of the map command?
I suspect there is one, so then we would need to "partialize" the output of blocklist in several map commands, it seems to me like it is a no-go.
On the other hand, my idea of invalidating the magic bytes and restore them after the mapping to (rd) is risky as if there is an error after the writing of the 44AA and before the restoring to the previous 55AA the source and or destination file may become invalid (it is a perfectly fixable issue, still it is "ugly", possibly even uglier than the 1+1, trick ).
Wonko
P.S. attached version 0.05, still Fn.42 meta-crc, but added the "n+1," trick, (the batch is a mess, will need some re-ordering/cleaning, but it seems like being working), I am particularly preoccupied by the loop to find first non-ending-with-55AA sector that might be invalid in some corner cases.