On Sat, Apr 4, 2009 at 2:49 PM, Richard <legalize at xmission.com> wrote:
It sounds like you're saying that metadata about
the file is lost
because FTP just transmits the file contents and not the metadata.
Pretty much.
(Similar to the data and resource forks on a Macintosh
file?)
Not that formal. With tapes, the out-of-band data wasn't part of the
data stream from your application, but your application could make
requests of the driver to write EOF and EOT "markers" and by the size
of the blocks you sent to the driver, created the aforementioned
metadata.
The solution seems to be to capture the file in a way
that captures
the metadata as well, like StuffIt for Mac files.
Is that it?
That's what "tape container files" are, in essence... imagine a
stream-of-bytes file, with a record size, then the "payload" then a
record size, with the ability to insert end-of-tape "markers" in the
file for whatever application is going to re-parse the file.
Such things exist now, but were not so common 20 years ago. We had
real tapes and we moved real tapes around - FTP and such became
popular on non-UNIX platforms later (well... there's FTP for TOPS-20,
but I didn't have any direct experience with that back in the day, so
I can't speak to what happened in that world).
-ethan