things that tar, the standard unix tape archive utility, does not do:
- detect the start or end of a continuous data stream (such as one being read from tape)
- add redundancy or error correction (such as you would use when archiving files)
- skip over corrupted blocks of data (instead it just gives up at the first sign of difficulty)
things tar does:
- puts a bunch of files into one big file and remembers their original filenames for you (you could do this trivially with like 10 lines of code in the scripting tool of your choice)
- compresses files, wait no I lied it actually just uses external utilities to do this anyway, which you could trivially just do yourself with this amazing tool called "piping"
so apparently tar was never implemented to be able to handle these problems directly because it actually expects them to be handled by a hardware peripheral. you don't write directly to the tape, you write to some sort of tape-reading-device which is expected to handle errors itself.
so I need to either build a dedicated tape control device in hardware, or fake it in software. the KISS protocol seems like as good a place to start as any. It's a minimalist way of marking the start and end of data, just use byte C0 to mark the start and end of a frame. if a C0 appears in your data for some reason, rewrite it as DB DC. if the escape character DB appears in your data, rewrite it as DB DD.
...except, what if I get an error there? I guess I could write a whole block of C0 bytes so that I can reliably detect the start and end of data even if there's a read error inside it. Except that then if the error occurs near the start or end of the frame I have to throw out the whole frame. So I should make the frames smaller and do forwards error correction. Which means I can't rely on running par2 to fix corruption, because that only works after the tar file arrives at its destination. I need to heal the file 'in transit'. Which means...
...I'm going to have to write my own damn non-trivial transceiver logic. damn.
okay so instead of using minimodem I'll just interface directly with pulseaudio. give me those raw pcm samples. and on the other end I'll expose standard in/out pipes I guess, and, uh... I'd want some sort of 'end of pipe' signal too, is that a thing? no, of course not, if you want to indicate that a file is 'done' you just stop sending data to it. so my transceiver should basically do something like
- wait for a 'start' signal from the tape
- start interpreting bits as packets
- do error correction and forward the 'healthy' packets through?
- wait for a 'stop' signal from the tape?
guhhh this is gonna be a whole ordeal, why are computers made of sand