LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: [1]   Go Down

Author Topic: (slightly offtopic) xenix tar behavior when files split across floppies  (Read 9801 times)

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +105/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm

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)
Code: [Select]
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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code
Pages: [1]   Go Up