On 5/22/12 1:06 AM, Christian Corti wrote:
On Mon, 21 May 2012, Richard wrote:
....and then you can email the FTP url to Al and
he can transfer to
bitsavers if he wishes.
That's how I do it and it works just fine.
Now that you mention this... I've done that in the past, too. But I would need to
send a (rather long) file list because I've sorted everything into subdirectories.
Christian
That really does work best for me. I normally either acknowledge when the files are
transferred, or
if they're small they just appear in the bitsavers hierarchy.
Jay runs the host that bitsavers is on, and there is only a single account on there with
no shell access.
I don't have any other machines that you can ftp into.
I'm in the middle of detailed specification of CHM's digital repository, and
haven't had many cycles
for anything other than a couple of outside projects that I need to get done in the next
month or two
so don't expect to hear much from me in a while. There is one project of general
interest that I may
talk about soon, which is a set of tools for transcoding raw media images into tarballs
with an
embedded extensible metadata file that looks like this (from a Tektronix fbr formatted
backup diskette)
TarXc_1.0
| Created: "2012-05-21 23:45:15 UTC"
| Format: "Tektronix fbr"
| Label: | Mode: 000777 | UID: 75 | GID: 15 | Sz: 989184 | Sbk: 3F |
Cks: 43 | Cre: "1984-04-10 00:22:06" | Mod: "1984-04-10 00:22:06" |
Nam: "REDOLAIR_SRCH_OK__APR9__16.00PM"
| File: 1 | Offs: 0 | Mode: 100644 | UID: 75 | GID: 15 | Sz: 3835 | Sbk: 3F |
Cks: 6E | Acc: "1984-04-09 23:33:55" | Mod: "1984-04-09 15:25:05" |
MD5: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
Path: "NEW_STUFF/jmc/attmess.asm"
| File: 2 | Offs: 0 | Mode: 100664 | UID: 75 | GID: 15 | Sz: 21639 | Sbk: 47 |
Cks: 4C | Acc: "1984-04-09 23:34:06" | Mod: "1984-04-03 23:18:11" |
MD5: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
Path: "NEW_STUFF/jmc/cmstar.asm"
| File: 3 | Offs: 0 | Mode: 100644 | UID: 75 | GID: 15 | Sz: 200 | Sbk: 72 |
Cks: 76 | Acc: "1984-04-06 23:29:05" | Mod: "1984-04-03 23:25:13" |
MD5: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
Path: "NEW_STUFF/jmc/cont.pan.ch"
| File: 4 | Offs: 0 | Mode: 100644 | UID: 75 | GID: 15 | Sz: 11817 | Sbk: 73 |
Cks: 79 | Acc: "1984-04-09 23:34:12" | Mod: "1984-04-09 12:47:15" |
MD5: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
Path: "NEW_STUFF/jmc/disp.drvs.asm"
It's not fully cooked yet (MD5 and file payload offsets are still missing)
It is interesting because tar is a really simple format to write, but is missing per file
checksums and
a fast way to randomly access an individual file. A metadata file with a magic file name
(__TarXc_TOC.txt)
as the first file in the tarball seems to solve this problem along with carrying
information that doesn't
translate from the original file format into the Unix world. Yes, I know it's not XML.
This was intentional
because I wanted it to look like a report, be fairly compact, and practical to parse.
"|" and ":" are the
keyword delimiters, certain keywords trigger nesting "Label:" and
"File:" and others (like "Mode:") are
context sensitive with things like a default radix associated with them. strings are
"" delimited and follow
Unix string conventions. Since file names may need to be munged into ones that Unix can
handle, the original
file name is maintained in the metadata file.
Another small tool that I needed to write for someone working on a Convergent floppy file
extractor converts
from IMD to RAW. It has one useful feature that it
writes a flaw and interleave map to stderr
http://bitsavers.org/bits/Convergent/ngen/imd2raw/
Keeping track of bad sectors is necessary when trying to note if an extracted file is
known to be bad because
of media flaws or if you have a flaw in the file system metadata.