So ran across something interesting trying to join the informix floppy images to a single tar file. What I did was to create a small dc42 tool that just saves all the data blocks together into a single file, thus providing a stream for tar.
However the problem is that when joined this way the end padding at the end of the first disk is all zeros, thus tar reads the zeros where it expects the next header as an EOF and bails out, making the files on the next disk inaccessible.\
And these extra zeros happen even if a file straddles two floppies such as is the case with /usr/bin/formbuild:
(this is from bvi)
00057DE8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 73 72 2F ........................usr/
00057E04 62 69 6E 2F 66 6F 72 6D 62 75 69 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bin/formbuild...............
00057E20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00057E3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00057E58 00 00 00 00 00 00 00 00 00 00 00 00 20 20 20 37 35 35 20 00 20 20 20 20 20 30 20 00 ............ 755 . 0 .
00057E74 20 20 20 20 20 30 20 00 31 33 36 30 30 30 00 34 36 32 34 20 20 33 33 32 30 34 32 35 0 .136000.4624 3320425
00057E90 37 35 36 20 20 31 30 32 35 35 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 756 10255. ................
00057EAC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00057EC8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00057EE4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00057F00 00 31 00 00 00 32 00 00 00 32 33 34 36 32 34 00 00 00 00 00 00 00 00 00 00 00 00 00 .1...2...234624.............
and here's the header for the 2nd piece:
00063FF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 73 72 2F 62 69 6E 2F 66 6F 72 6D ................usr/bin/form
0006400C 62 75 69 6C 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 build.......................
00064028 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00064044 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00064060 00 00 00 00 20 20 20 37 35 35 20 00 20 20 20 20 20 30 20 00 20 20 20 20 20 30 20 00 .... 755 . 0 . 0 .
0006407C 37 36 36 32 34 00 00 34 36 32 34 20 20 33 33 32 30 34 32 35 37 35 36 20 20 31 30 32 76624..4624 3320425756 102
00064098 31 35 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15. ........................
000640B4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
000640D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
000640EC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00 00 32 00 00 .....................2...2..
00064108 00 32 33 34 36 32 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .234624.....................
00064124 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00064140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
0006415C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00064178 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
00064194 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
000641B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
000641CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............................
000641E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF F0 21 6E ..........................!n
[code]
Note that the size field for the first segment is "136000" and for the second is "76624" but the actual size is 80276 bytes. In octal it's 234624, so adding 13600 + 7624 in octal gives us 234624 so that's fine. (tar headers are octal encoded ascii strings.)
But if I remove the zero space and allow the two segments of usr/bin/formbuild to be joined together in a single tar file, gnu tar on Linux will overwrite the first half of the file with the second half of the file rather than append to it. (note that I didn't change the headers in any way, but I had to delete the extra NULs to allow it to recognize the next segment.)
[code]-rwxr-xr-x 0/0 42192 1984-06-28 21:41 usr/bin/informix
-rwxr-xr-x 0/0 80004 1984-06-28 21:41 usr/bin/dbbuild
-rwxr-xr-x 0/0 73446 1984-06-28 21:41 usr/bin/dbstatus
-rwxr-xr-x 0/0 65586 1984-06-28 21:42 usr/bin/enter1
-rwxr-xr-x 0/0 94420 1984-06-28 21:44 usr/bin/perform
-rwxr-xr-x 0/0 48128 1984-06-28 21:44 usr/bin/formbuild
-rwxr-xr-x 0/0 32148 1984-06-28 21:44 usr/bin/formbuild
-rwxr-xr-x 0/0 69000 1984-06-28 21:42 usr/bin/enter2
-rwxr-xr-x 0/0 100704 1984-06-28 21:42 usr/bin/informer
-rwxr-xr-x 0/0 51672 1984-06-28 21:43 usr/bin/aceprep
-rwxr-xr-x 0/0 94082 1984-06-28 21:43 usr/bin/acego
-rwxr-xr-x 0/0 42096 1984-06-28 21:48 usr/bin/bcheck
-rw-r--r-- 0/0 340 1984-06-10 20:43 usr/lib/informix/storeform
-rw-r--r-- 0/0 1572 1984-06-10 20:43 usr/lib/informix/realform
-rw-r--r-- 0/0 676 1984-06-28 12:40 usr/lib/informix/storeform.frm
-rw-r--r-- 0/0 2252 1984-06-28 12:40 usr/lib/informix/realform.frm
-rw-r--r-- 0/0 142 1984-06-10 20:43 usr/lib/informix/custschem
-rw-r--r-- 0/0 136 1984-06-10 20:43 usr/lib/informix/ordschem
-rw-rw-rw- 0/0 333 1984-06-28 12:45 usr/lib/informix/orders.dat
-rw-rw-rw- 0/0 3072 1984-06-28 12:45 usr/lib/informix/orders.idx
...
So from the looks of this, I'll need to interpret the tar headers and recognize when this happens, join the two data streams together and go back and modify the original header with the actual total size. I didn't see anything in the tar specification for this.
This might also apply to uniplus, not sure.
I'm wondering if there's something in the header that's documented somewhere that says this is a segment of a file that's continued on the next disk that I can recognize.
Now since I'm processing multiple floppies I can tell when when I'm about to reach the end, but the weird thing is that Xenix tar purposely left the last 32 sectors or so filled with nulls rather than fill the disk all the way to the end. I'd have expected it to fill all the way to the end and use the hardware EOF of the drive to tell it where it ended, but no. Maybe it's doing something like leaving the last track empty or something weird like that, but I don't understand why it would do that.