mechcrm@tness1.UUCP (Chet Murthy 713+680-8841) (12/19/87)
Hi. I am in the process of writing a multiple-volume tar/cpio/backup
utility. i have already tried to build one into cpio, with moderate success -
the code is so bloody (no flames, please) messy that there's no way to do it
without a major rewrite. So, I thought of hacking the public domain tar that
was posted to comp.sources.unix recently. This would have the advantage
that I could freely distribute the mods. Now, the questions:
I would appreciate any answers to these to be mailed soonest, as I will
be working on this for the next 3 weeks only. At the end of that time, I
will probably never see this code again.
What exactly would be useful in a multivolume tape backup utility, assuming
it was based on tar?
one of the major ffeatures taht I have already had pointed out to me is the
ability to randomly access data on any tape. That is, if the archive is
15 tapes long, and we want to get at data on the 10th tape, we don't want to
read all of the tapes 1-9. In addition, we want a 'roadmap" which will
tell us approximately what is on each tape. This might be a list of files
on the last tape. Anyway, I would appreciate any information that
anybody out there could provide on this.
Also, if anybody has a copy of the POSIX standard for tar formats, could
they please Email it to me? That way, i can understand exactly what to do
to make my mods more standard.
thanks a lot,
--chet--
Chet Murthy
Southwestern Bell Telephone, Dallas, Texas
Email: ...!ihnp4!tness1!mechcrm
murthy@svax.cs.cornell.edumkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (12/23/87)
in article <341@tness1.UUCP>, mechcrm@tness1.UUCP (Chet Murthy 713+680-8841) says: > Hi. I am in the process of writing a multiple-volume tar/cpio/backup > utility... > > What exactly would be useful in a multivolume tape backup utility, assuming > it was based on tar? Ultrix has a multivolume tar called "mdtar" (multiple diskette tar -- don't ask why). It works fine except for one irritating feature: it prompts for the next volume on standard error, and also prints the "v" flag's output on standard error. I'd prefer if the prompts were on a separate stream from the verbose output (e.g., design a new flag that would send the "v" flag's output to a file). Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (12/24/87)
In article <341@tness1.UUCP> mechcrm@tness1.UUCP (Chet Murthy 713+680-8841) writes: | | Hi. I am in the process of writing a multiple-volume tar/cpio/backup | utility. i have already tried to build one into cpio, with moderate success - | the code is so bloody (no flames, please) messy that there's no way to do it | without a major rewrite. So, I thought of hacking the public domain tar that | was posted to comp.sources.unix recently. This would have the advantage | that I could freely distribute the mods. Now, the questions: About six months ago I posted a program set called "bundle" which allowed multivolume on *any* program able to use stdin and stdout for devices. Perhaps this would save you a bit of time. I'm getting a SysV specific version going with shared memory which is somewhat faster, but the released version should do what you want. tar cf - | bundle /dev/mt0 10000k 4k find . -print | cpio -oc | bundle /dev/mt0 10000k 4k In a few months I will be releasing a version which also handles multivolums on separate physical devices, allowing mounting of one tape while the other is writing. A novel reinvention of 1962 GECOS (sic). Let me know if you need this and can't find it. It was in comp.sources.unix. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ford@crash.cts.com (Michael Ditto) (12/28/87)
In article <341@tness1.UUCP>, mechcrm@tness1.UUCP (Chet Murthy 713+680-8841) says: > Hi. I am in the process of writing a multiple-volume tar/cpio/backup > utility... > > What exactly would be useful in a multivolume tape backup utility, assuming > it was based on tar? It must make each volume (disk, tape, or whatever) usable even if others in the set are lost. In other words, the obvious technique of simply splitting the archive into N-block chunks (where N is the size of a disk or tape) is inconvenient, because if any volume is lost, all volumes after it are essentially useless. If this simple solution is sufficient, however, it can be implemented with a shell script. For example, (from memory, this probably wont work exactly as is): # "mdtarout" (multiple disk tar output) assumes a disk is 800 blocks. tar -cvf - "$@" | ( while echo 'Insert the next disk and press return\c' >/dev/tty read x < /dev/tty do dd count=800 > /dev/floppy || exit done ) exit # "mdtarin" (multiple disk tar input) assumes a disk is 800 blocks. ( while echo 'Insert the next disk and press return\c' >/dev/tty read x </dev/tty do dd count=800 < /dev/floppy || exit done ) | tar -xvf - "$@" exit I use something like the above for making backups which I don't expect to use unless something catastrophic happens, or for transferring a large software package that would be useful if extracted as a whole. The only reason to write a multi-volume tar would be to make it better than the above shell scripts can be; i.e. to split the volumes at file boundries, and such. Even that can be done with existing tools like awk. If you write such a program it had better be loaded with user-friendly niceties to make it worth using. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM