Here be dragons..
Well, the answer to the above question. I can guarantee that anyone reading this who has ever done any command line work with files (e.g. in Dos) or just about any operating system that has some form of command shell will go "Oh yes, I see it now".
Explanation of my file naming conventions:.
If I have a set of files that are specifically "linked together as part of a set" then it makes sense to have something within the filename that indicates this.
e.g. A large file named "bigfile.txt". If I decide to split this file into smaller parts (the reason is irrelevant here), then naming the file portions in this manner is a good idea. e.g.
bigfile.txt.part1 , bigfile.txt.part2 , bigfile.txt.part3 and so on.
I can then look at the filenames and identify what they are immediately. To obtain the original "bigfile.txt" all I need to do is to join all of the parts together in the correct order.
As an extension to the process of splitting files, it's often a good idea to use some means of identifying if any file corruption has occurred.
This might be either in file storage (degrading storage media etc.) or in transmission across the internet..
One of the tools that I use for consistency checking purposes creates a text file containing this information. I tend to not use a tool that embeds this information into the relevant file (e.g. Winrar or Winzip type embedded recovery records) as I often want to be able to use the "raw" file with any tool that I choose. I therefore use the same filename with an appended ".sha256". I can then immediately identify which checksum file is needed with any particular file.
In order to recreate the full drive image from compressed "parts" correctly, I need to be able to identify each part in the order that it is going to be used.
Part of the command to do this uses "wildcards".
Using the "clue" example filenames from my earlier post, I need to be able to pass each file "onwards" in the correct order.
Again from the above post (for windows),
dir myfile.gz_* will return a file listing in alphabetical order.
Specifically, the directory listing will be an alphabetically sorted list of files whose names begin with myfile.gz_
This would include a file called "myfile.gz_Part1" and also "myfile.gz_Very-Long-Name-But-Not-What-I-Want-Here".
The command has done exactly what it was told to, but not quite what I wanted it to do. Subtle difference!
To list only the files that I want (using wildcards) but not the checksum files, then I need to alter the command slightly.
dir myfile.gz_* returns this:
I only want this:
The correct command for this example is:
This means show all files, in alphabetical order, whose filename begins "myfile.gz_a" followed by only one character.
So... the correct extract and write command for the tablet full drive archive is:
wait for it, wait for it...
cat Linx7FullDrive.img.split.gz_a? | gunzip -c > /dev/mmcblk0
I had tested that the original command did work.. It did, until the checksum files were added to the same directory.
The "error" made the command take the first archive part, extract and write it to the drive. It then tried to do the same to the next file, which in this case was the checksum file, not the second archive part.
If anyone has managed to read this far without falling asleep then.. I award you an honorary cookie.
Sorry to waffle on again...