dump/restore

[Guy Harris]

>  Hopefully one of the things which will come out of the xenix SysV
>merge is dump again. The V.4 info seems to say you can dump the fast
>filesystem stuff but not the SysV f/s's. Since xenix does this, it can't
>be *that* hard!

The history here is a bit interesting.  Basically, "dump"/"restor" (no
"e", notice) came from V7.  AT&T marked it as "deprecated" in S3, and
dropped it in S5.  Other vendors, such as, presumably, Microsoft, saw no
reason to drop it....

4BSD didn't drop it either; in fact, they beefed "dump" up quite a bit. 
"dump" was then rewhacked quite a bit to make the 4.2BSD version (and
then rewhacked some more to make the 4.3BSD version).

Probably, if you want "dump" for the System V file system, you should
start with the 4.1BSD version, and whack it as necessary to support file
systems with a block size other than 1K (and maybe throw in goodies from
the 4.2BSD and 4.3BSD ones as well, such as "remote magtape" support and
the multiple buffering stuff).

"restor(e)" is a different question.  You should definitely start with
the 4.1BSD one (since, as I remember, it understands the "s_tfree" and
"s_tinode" fields, while the V7 one and even the S3 one didn't).  You
definitely want to add the "restore by name" feature that "restore" has
- it's a colossal win.   I don't know whether it should restore only to
a directory, rather than a raw file system, as "restor" does.

I suspect that, if S5R4 doesn't have "dump" or "restor(e)" for the S5
file system, it's only because they don't like it and think
"volcopy"/"finc"/"frec"/"frick"/"frack"/... are better, or because they
don't have the effort to invest in bringing it back.