jl42+@andrew.cmu.edu (Jay Mathew Libove) (04/25/88)
Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and
I am having a bit of a problem with "tar".
I want to tar off a filesystem as:
% tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 -
but when I do this I get:
tar: blocksize must be a multiple of 2.
Anyone know why this doesn't work, or how I could do this? I could also
use afio/cpio for the second tar, but I want the first tar to be a tar
so I can read back the archive, decompress it, and extract lists and
individual files.
Thanks!
Jay Libove
Arpa: Jay.Libove@andrew.cmu.edu Bitnet: Jay.Libove@drycas.bitnet
UUCP: ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!Jay.Libove
UUCP: ...!{pitt | bellcore} !darth!libove!libovedavidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/26/88)
In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and | I am having a bit of a problem with "tar". | I want to tar off a filesystem as: | | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - | | but when I do this I get: | | tar: blocksize must be a multiple of 2. This must be a new feature of 2.2.1, it's not in 2.1.3 and I don't have a handy copy of 2.2.1 here. I see what you're trying to do (I think) and would suggest the bundle/unbundle package I posted to unix.src a few months ago. It is intended to break standard input across a number of output media, such as floppy disk, and I think it does what you want. The unbundle part reads multiple media and sends them to stdout. Ex: $ tar -cf - /mydir | compress | bundle /dev/rfd096 1200k 15k $ unbundle /dev/rfd096 15k | zcat | tar t If you don't have archives I can send you a copy. Be sure and give me an address in the text so the return will work. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
haugj@pigs.UUCP (John F. Haugh II) (04/29/88)
> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: > | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and > | I am having a bit of a problem with "tar". > | I want to tar off a filesystem as: > | > | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - > | > | but when I do this I get: > | > | tar: blocksize must be a multiple of 2. this must be an april's fools day joke of some kind. the person (jay libove) who posted the original article has made too many mistakes for this to be simple stupidity. first off, last time i checked there was no 96 tpi 9 sector device. the only 96 tpi device was 15 sectored. secondly, you have two tar's with the 'c' option in the pipe line. 'c' stands for 'create archive', so the input of the second tar is coming from the files requested to be archived. the /dev/rfd096ds9 [sic] device is going to be the output device, not standard output as requested with the '-' option. thirdly, assuming jay meant to use 'x' on the second tar, which is the only way for two tars in a pipe to work, the input would have been coming from compress, which is not in tar format. you are lucky you only received a blocksize message. i suppose the correct response now would be `RTFM'. - john. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!ihnp4!killer!rpp386!jfh jfh@rpp386.uucp :DOMAIN "You are in a twisty little maze of UUCP connections, all alike" -- fortune
karl@ddsw1.UUCP (Karl Denninger) (05/02/88)
In article <100@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes: >> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: >> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and >> | I am having a bit of a problem with "tar". >> | I want to tar off a filesystem as: >> | >> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - >> | >> | but when I do this I get: >> | >> | tar: blocksize must be a multiple of 2. > >this must be an april's fools day joke of some kind. the person (jay libove) >who posted the original article has made too many mistakes for this to be >simple stupidity. > >first off, last time i checked there was no 96 tpi 9 sector device. the >only 96 tpi device was 15 sectored. My Xenix system (2.2.1, no wierd stuff) shows the following: brw-rw---- 1 asg mail 2, 52 Mar 23 15:27 /dev/fd0 brw-rw-rw- 2 root mail 2, 4 Apr 10 23:23 /dev/fd048 brw-rw-rw- 1 root mail 2, 12 Jun 29 1987 /dev/fd048ds8 brw-rw-rw- 2 root mail 2, 4 Apr 10 23:23 /dev/fd048ds9 brw-rw-rw- 1 root mail 2, 8 Jun 29 1987 /dev/fd048ss8 brw-rw-rw- 1 root mail 2, 0 Jun 29 1987 /dev/fd048ss9 brwx---rw- 1 root root 2, 52 Apr 30 20:27 /dev/fd096ds15 brw-rw---- 1 asg mail 2, 36 Apr 10 23:12 /dev/fd096ds9 There are also raw devices to correspond with each of these. >secondly, you have two tar's with the 'c' option in the pipe line. 'c' >stands for 'create archive', so the input of the second tar is coming from >the files requested to be archived. the /dev/rfd096ds9 [sic] device is >going to be the output device, not standard output as requested with the >'-' option. > >i suppose the correct response now would be `RTFM'. Let's be a little more charitable, ok? I take it you're trying to compress the data stream as it goes to disk. To do this successfully you need a program that will block the data into disk-sized chunks, and prompt for additional disks. Given such a program called 'stream', for example, you do this: tar cf - /pathname | compress | stream >/dev/rfd096ds9 If you know that the data will fit on one disk you can do: tar cf - /pathname |compress >/dev/rfd096ds9 But if this returns an "out of space" error you're hosed -- it will not wait for you to change disks. If your archive doesn't fit on a single disk, and you don't have a 'streamer' you've got a real live problem. I don't know of any good solutions to it either -- what you're trying will not work, as the second 'tar' is looking for *filenames* to fetch on it's standard input and you're sending it compressed *data*. Note that the 'raw' device is *necessary* as you must insure that no data remains buffered in the cache before attempting to change disks lest some of the data not be on the disk later when you go looking for it! (BTW: Those of you who are using floppies, and not using 'afio' (the cpio replacement posted earlier on) should *seriously* consider it. The best feature is the ability to pick up in the middle of an archive, AND skip over bad spots in the media. If there is enough interest I can make it available for anonymous uucp.) ----- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"
samperi@marob.MASA.COM (Dominick Samperi) (05/02/88)
In article <100@pigs.UUCP> you write: |> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: |> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and |> | I want to tar off a filesystem as: |> | |> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - |> | |> | but when I do this I get: |> | |> | tar: blocksize must be a multiple of 2. | |first off, last time i checked there was no 96 tpi 9 sector device. the |only 96 tpi device was 15 sectored. This is the driver for 720K formatted, DD floppies, where there ARE 9 sectors per track. The only way to do what you want (short of modifying the tar source) is: tar cvf /tmp/whatever /pathname compress /tmp/whatever tar cvf /dev/rfd096ds9 /tmp/whatever.Z Alternatively, you could use one tar, compress, and dd, in a pipeline something like: tar cvf - /pathname | compress | dd of=/dev/rfd096ds9 (you may need to supply a few more dd switches to get this to work properly, and efficiently). --- Dominick Samperi, Manhattan College, NYC manhat!samperi@NYU.EDU ihnp4!rutgers!nyu.edu!manhat!samperi philabs!cmcl2!manhat!samperi ihnp4!rutgers!hombre!samperi (^ that's an ell) uunet!swlabs!mancol!samperi
lbr@holos0.UUCP (Len Reed) (05/03/88)
in article <100@pigs.UUCP>, haugj@pigs.UUCP (John F. Haugh II) says: > >> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: >> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and >> | I am having a bit of a problem with "tar". >> | I want to tar off a filesystem as: >> | >> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - >> | >> | but when I do this I get: >> | >> | tar: blocksize must be a multiple of 2. > > this must be an april's fools day joke of some kind. the person (jay libove) > who posted the original article has made too many mistakes for this to be > simple stupidity. You must be an expert on simple stupidity. I suggest that if you must be insulting you shouldn't make so many errors in your comments. You have supplied incorrect information, probably misinterpreted the intention of the original poster, failed to provide a solution, and failed to explain the real source of the error message. > > first off, last time i checked there was no 96 tpi 9 sector device. the > only 96 tpi device was 15 sectored. On your system, perhaps. On the distribution system, perhaps. The manuals describe how to make a device that is any combination of {ss,ds}, {8,9,15} sectors per track, {48,96} tracks per inch. Floppy device zero with double sided 96 TPI, 9 SPT is minor device 36. This format is useful for getting the maximum amount of data (720K, the amount Jay specified in his tar command) on a non high-density diskette. (In a strictly literal sense, /dev/rfd096ds9 is not necessarily device (2,36)--it is whatever the filesystem says it is. I'm assuming that Jay simply extended the existing naming conventions or that you're wrong about what comes with the system. I have a /dev/rfd096ds9, but I may have made it myself. Refer to the doecumentation on mknod(1), John, for how to add character-special devices.) The ability to read and write almost any diskette is a very usful feature of Xenix. I often have to shuffle files to/from an NCR Tower, which uses 96 tpi, ds, 8 spt == 640K. I even have /dev/rfd096ds8 linked to /dev/rtower, further demonstrating my parenthetical remark above. > > secondly, you have two tar's with the 'c' option in the pipe line. 'c' > stands for 'create archive', so the input of the second tar is coming from > the files requested to be archived. the /dev/rfd096ds9 [sic] device is > going to be the output device, not standard output as requested with the > '-' option. True, but I think he wants '-' to be the input device. (See below.) > > thirdly, assuming jay meant to use 'x' on the second tar, which is the > only way for two tars in a pipe to work, the input would have been coming > from compress, which is not in tar format. you are lucky you only received > a blocksize message. It appears to be true that for two tars to work in a pipeline, the first must be output to stdout and the second input from stdin. I doubt that Jay wanted to extract in the second tar. My guess is that the intention was: First tar packs up the files into a tar archive and writes the archive to the pipe. Compress squeezes the tar archive and passes it along. Second tar reads the compressed archive and writes a tar archive containing a single file that is the compressed tar archive. Tar (on Xenix) can read the stdin OR write the stdout, but it doesn't appear to be able to do both at once. (Surely the '-' in the second tar command meant read the stdin.) The problem is that tar won't accept tar cff - output_device which seems to be what is wanted. If the output of compress will be less than 720K, you can say tar cf - /pathname | compress | dd obs=20k of=/dev/rfd096ds9 If you REALLY need compress and > 720K, you may have to a little programming. Tar won't read from a fifo, so this won't help. (John probably didn't consider this option since his system can't have fifos--they're built by mknod.) I know of no Xenix commands other that backup/dump and tar that handle multiple diskette volumes. I you can afford the hard disk space: tar cf - /pathname | compress >result tar cfkb /dev/rfd096ds9 720 20 result where "result" is a normal file. Note the addition of "b" and 20: these specify the blocking factor of 20. The default blocking factor is 1, which apparently is unacceptable here. Omitting the blocking factor yields "tar: blocksize must be a multiple of 2." (Look familiar?) It's better, though, to edit /etc/default/tar to include a line describing the device, and then use its number in the command. E.g., add the line archive4=/dev/rfd096ds9 20 720 n and the use command tar c4 result instead of tar cfkb /dev/rfd096ds9 720 20 result Better compression be might be achieved by copying the entire heriarchy (using cpio or tar), compressing the individual files, and then tarring the shadow heirarchy. Even if the compress step were done as part of the heariarchy copy, using a script with a loop in it, you need hard disk space for the whole compressed heirarchy. (This also has the advantage that the files on the diskette will be listable using "tar t" or "cpio -t".) If you need multiple volumes and don't have the hard disk space for a copy, you could create a simple filter that copies from stdin to stdout, stopping every 720K (or better, an arbitrary amount) to ask for confirmation to continue from /dev/tty. Such a filter could be placed in a pipeline between packaging (cpio or tar plus compress) and output (probably dd). find /pathname -print | cpio -oc | compress | new_filter 720k | dd obs=20k of=/dev/rfd096ds9 You'll also need a way of reading the floppies. Perhaps appending each floppy to a fifo while reading the fifo with uncompress. (Use cpio instead of tar to build the archive.) I don't recommend you do it this way, though. Having a single compressed file strewn over several diskettes, requiring diskette concatination and uncompress to even list the archive contents is awkward at best. There must be better ways to get floppies with compressed archives. I haven't used it, but perhaps "zoo" is what you want.
john@jetson.UUCP (John Owens) (05/03/88)
In article <100@pigs.UUCP>, haugj@pigs.UUCP (John F. Haugh II) writes: > > In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: > > | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - > this must be an april's fools day joke of some kind. the person (jay libove) > who posted the original article has made too many mistakes for this to be > simple stupidity. Actually, he's only made one mistake, and it's not a surprising one for a UNIX neophyte. (Be a bit more charitable.) > first off, last time i checked there was no 96 tpi 9 sector device. the > only 96 tpi device was 15 sectored. My xenix supports 96ds9 just fine - there's no reason not to use quad density diskettes if you want to, and if he's running on some kind of system other than an AT-compatible that has quad density but not high density, that's what he'd want to use. Certainly his 720k figure is correct for 96ds9.... There are two ways to do what he wants to do, both with drawbacks. One is % cd / ; tar cf - pathname | compress | dd of=/dev/rfd096ds9 bs=1k but this won't handle multiple diskette switching. Another way is % cd / ; tar cf - pathname | compress > /tmp/tar.Z % tar cfk /dev/rfd096ds9 720 /tmp/tar.Z but this won't work if you don't have enough tmp space to hold the file (or if you're trying to tar something including /tmp). If tar could read the contents of a fifo, you could get around this, but it doesn't. By the way, I used "cd / ; tar cf - pathname" instead of "tar cf - /pathname" to make it easier to restore. If the files in your tar archive start with a '/', you can only restore them to their original locations. If they do not, they will be restored under the current directory, so you could either cd / to restore them there or cd /somewhere-else to restore them under /somewhere-else. If anyone can expand on these suggestions to allow writing to multiple diskettes, please post. (I vaguely remember a program posted years ago to write the standard input to multiple tapes/diskettes; if this exists somewhere, it could probably be used as % cd / ; tar cf - pathname | compress | multi-write /dev/rfd096ds9 720 or something like that.) -- John Owens SMART HOUSE Development Venture john@jetson.UUCP (old uucp) uunet!jetson!john +1 301 249 6000 (internet) john%jetson.uucp@uunet.uu.net
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/03/88)
haugj@pigs.UUCP (John F. Haugh II) writes: | > jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: | > | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and | > | I am having a bit of a problem with "tar". | > | I want to tar off a filesystem as: | > | | > | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - | this must be an april's fools day joke of some kind. the person (jay libove) | who posted the original article has made too many mistakes for this to be | simple stupidity. | | first off, last time i checked there was no 96 tpi 9 sector device. the | only 96 tpi device was 15 sectored. [ you have a defective copy of Xenix. It's in all of mine from 2.1.2 forward. You can create any combination of 8, 9, or 15 track, single or double sided if you can find a use for it. It's minor device 36 on the system I'm using. ] | i suppose the correct response now would be `RTFM'. [ no comment. ] | - john. | -- | The Beach Bum Big "D" Home for Wayward Hackers | UUCP: ...!ihnp4!killer!rpp386!jfh jfh@rpp386.uucp :DOMAIN -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/04/88)
Okay people, I mentioned that this has been posted to unix.src before,
but since there is so much interest in this, here is the program which
reads from stdin and writes multiple output media (be they disk, tape,
or whatever). Don't use buffer size > 30k, I suggest size = 1 cylinder
for best speed.
I suspect that most of the response came not from the original question,
but from the first flaming response.
#!/bin/sh
# shar: Shell Archiver (v1.22)
#
# Run the following text with /bin/sh to create:
# bundle.1
# bundle.c
# unbundle.c
#
echo "x - extracting bundle.1 (Text)"
sed 's/^X//' << 'SHAR_EOF' > bundle.1 &&
X'\" Copyright 1986,87 by Bill Davidsen. This code may be used for
X'\" personal or commercial purposes. It may be freely distributed
X'\" in source form providing this notice is kept intact.
X.TH bundle 1 Local
X'\" Heading: name(sect) center (paren) name(sect)
X.SH NAME
Xbundle \- buffer and copy \fIstdin\fR to a physicaql device
Xunbundle \- buffer and copy a physical device to \fIstdout\fR
X.SH SYNOPSIS
X\fBbundle\fR special dev_size buf_size
X.br
X\fBunbundle\fR special buf_size
X.SH DESCRIPTION
XThese programs allow a physical device to be the head or end of a pipe,
Xallows software which does not know about volumes to operate on
Xmulti-volume sets, and improves the performance of programs such as
X\fItar\fR and \fIcpio\fR.
X.P
X\fBSpecial\fR is the name of a raw device, such as /dev/rmt0.
X\fBdev_size\fR is the size of the device, given in bytes or kilobytes.
XWhen \fBdev_size\fR bytes have been written to the output device, the
Xoperator will be prompted for a media change. \fBBuf_size\fR is the size
Xof the buffer for the write or read. For tape this should be the desired
Xtape block size. For disk this should be a multiple of the size of a
Xtrack. For disk output writing a track at a time rather than sectors
Xcan reduce real time by a factor of three.
X.SH EXAMPLES
X ls *.c | cpio -o | bundle /dev/rfp021 395k 5k
X unbundle /dev/rfp021 5k | cpio -idm
X tar cf - /usr/local | bundle /dev/rmt0 4000k 8k
X unbundle /dev/rmt0 8k | tar cf -
X.SH WARNINGS
X\fIunbundle\fR reads to EOF on the input device. There is no way to read
Xonly part of a volume. If the \fBdev_size\fR is not a multiple of the
X\fBbuf_size\fR, bizarre errors may occur.
X.SH FILES
X/dev/\fBspecial\fR
X.SH SEE ALSO
Xtar, cpio.
X.SH AUTHOR
XBill Davidsen (ihnp4!chinet!crdos1!davidsen)
X'\" For more details, see man(7), as well as man(1), manroff(1), and mmt(1)
SHAR_EOF
chmod 0644 bundle.1 || echo "restore of bundle.1 fails"
echo "x - extracting bundle.c (Text)"
sed 's/^X//' << 'SHAR_EOF' > bundle.c &&
X/*****************************************************************
X | Program name: bundle.c
X |----------------------------------------------------------------
X | accept standard input and write to a device named on the command
X | line. The total bytes on the device and the buffer size are
X | given on the command line. When the device is full, prompt
X | for a new medium in the device and continue.
X |
X | Command form:
X | bundle device Dsize Bsize
X |----------------------------------------------------------------
X | Author: Bill Davidsen, 8/16/86
X | Version 1.6
X | Last modified: 3/6/87
X |----------------------------------------------------------------
X | Copyright 1986,87 by Bill Davidsen. This code may be used for
X | personal or commercial purposes. It may be freely distributed
X | in source form providing this notice is kept intact.
X *****************************************************************/
X
X#include <stdio.h>
X
X#ifdef DEBUG
X#define debug(f,v) fprintf(stderr, f, v)
X#else
X#define debug(f,v)
X#endif
X
Xstatic char *SCCS = "@(#) bundle 1.6";
X
Xmain (argc, argv)
X int argc;
X char *argv[];
X{
X char *buffer, /* i/o buffer */
X *malloc ();
X register long left; /* room left in the buffer */
X long bufsize, devsize; /* buffer and device size */
X long devleft = 0; /* room left on device */
X int istat, /* stdin read status */
X ostat, /* device write status */
X dev, /* device name from open */
X MediaNum = 1; /* sequential media # */
X FILE *tty, *fopen ();
X long getsize (); /* get size from argument */
X
X /* validate arguments */
X if (argc != 4)
X { /* invalid */
X printf ("Format:\n bundle device DevSize BufSize\n");
X printf ("Where size may be bytes (as 5120) or k (as 5k)\n");
X exit (1);
X }
X
X devsize = getsize (argv[2]);
X debug ("Device size %ld", devsize);
X bufsize = getsize (argv[3]);
X debug (", buffer size %ld\n", bufsize);
X if (devsize < 1 || devsize < bufsize)
X { /* invalid specification of size */
X printf ("Invalid buffer and/or device size\n");
X exit (1);
X }
X
X /* open the terminal for prompt */
X tty = fopen ("/dev/tty", "r");
X if (tty == NULL)
X { /* mystery failure */
X printf ("Unable to open /dev/tty for prompt\n");
X exit (1);
X }
X
X /* open the buffer */
X buffer = malloc (bufsize);
X debug ("Buffer allocated\n", 0);
X if (buffer == NULL)
X { /* can't mallocate */
X printf ("Can't allocate space for the buffer\n");
X exit (1);
X }
X
X /* see if you can open the device */
X printf ("Mount media #1 on %s and press RETURN", argv[1]);
X while (getc (tty) != '\n');
X dev = open (argv[1], 1);
X if (dev < 0)
X { /* invalid name */
X printf ("Can't access device %s\n", argv[1]);
X exit (1);
X }
X devleft = devsize; /* set media ready */
X debug ("Enter copy loop\n\n", 0);
X
X /* main copy loop */
X while (istat = fread (buffer, 1, (int) bufsize, stdin))
X { /* until EOF */
X debug ("Input read size %d\n", istat);
X
X if (devleft < istat)
X { /* change media */
X close (dev);
X printf ("\007Mount media #%d on %s and press RETURN: ",
X ++MediaNum, argv[1]);
X while (getc (tty) != '\n');
X dev = open (argv[1], 1);
X devleft = devsize;
X }
X
X /* write the buffer */
X ostat = write (dev, buffer, bufsize);
X debug ("Output write size %d\n", ostat);
X
X if (bufsize != ostat)
X { /* error on write */
X printf ("Error on device write!\n");
X exit (1);
X }
X devleft -= ostat;
X }
X}
X
X/*
X | Procedure: getsize
X |-
X | Convert the size string to bytes. If the last character is
X | 'k', multiply by 1024
X */
X
Xlong
Xgetsize (string)
X char *string;
X{
X register long len = strlen (string),
X val = atol (string);
X
X if (string[len - 1] == 'k')
X val *= 1024;
X
X return val;
X}
SHAR_EOF
chmod 0444 bundle.c || echo "restore of bundle.c fails"
echo "x - extracting unbundle.c (Text)"
sed 's/^X//' << 'SHAR_EOF' > unbundle.c &&
X/*****************************************************************
X | Program: unbundle
X | accept input from a device and write to stdout
X |----------------------------------------------------------------
X | Arguments:
X | 1) device name
X | 2) block size in bytes or k
X | Version: 1.6
X | Last modified: 3/6/87
X |----------------------------------------------------------------
X | Copyright 1986,87 by Bill Davidsen. This code may be used for
X | personal or commercial purposes. It may be freely distributed
X | in source form providing this notice is kept intact.
X ****************************************************************/
X
X#include <stdio.h>
X
X#ifdef DEBUG
X#define debug(f,v) fprintf(stderr, f, v)
X#else
X#define debug(f,v)
X#endif
Xmain (argc, argv)
X int argc;
X char *argv[];
X{
X char *buf, *malloc ();
X int bufsize, dn, mnum = 1, ch, readsize;
X static char *SCCSid = "@(#)unbundle 1.6";
X long getsize (); /* size of buffer */
X
X if (argc != 3)
X { /* bad calling sequence */
X fprintf (stderr, "%s: wrong # of arguments\n", argv[0]);
X fprintf (stderr, "Calling seq:\n %s device bufsize\n",
X argv[0]);
X exit (1);
X }
X
X /* try to open the device */
X dn = open (argv[1], 0);
X if (dn < 0)
X { /* open failed */
X fprintf (stderr, "%s: can't open device %s\n", argv[0], argv[1]);
X exit (1);
X }
X close (dn); /* so I can reopen */
X
X /* allocate the buffer */
X bufsize = getsize (argv[2]);
X debug ("Bufsize: %d\n", bufsize);
X
X buf = malloc (bufsize);
X if (buf == NULL)
X { /* can't allocate the buffer */
X fprintf (stderr, "Can't allocate %d byte buffer\n", bufsize);
X exit (1);
X }
X
X for (;;)
X { /* get a fresh mount and read it */
X fprintf (stderr, "Mount input medium #%d on %s and press return: ",
X mnum++, argv[1]);
X read (0, &ch, 1);
X open (argv[1], 0);
X
X while (readsize = read (dn, buf, bufsize))
X write (1, buf, readsize);
X close (dn);
X }
X}
X
X/*
X | Procedure: getsize
X |-
X | Convert the size string to bytes. If the last character is
X | 'k', multiply by 1024
X */
X
Xlong
Xgetsize (string)
X char *string;
X{
X register long len = strlen (string),
X val = atol (string);
X
X if (string[len - 1] == 'k')
X val *= 1024;
X
X return val;
X}
X
SHAR_EOF
chmod 0444 unbundle.c || echo "restore of unbundle.c fails"
exit 0
I wrote this because I needed it myself, hopefully it will be useful to
others.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memike@ists (Mike Clarkson) (05/04/88)
In article <508@holos0.UUCP>, lbr@holos0.UUCP (Len Reed) writes: > in article <100@pigs.UUCP>, haugj@pigs.UUCP (John F. Haugh II) says: > > > >> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: > >> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and > >> | I am having a bit of a problem with "tar". > >> | I want to tar off a filesystem as: > >> | > >> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - You don't really want to do this (trust me I know :-). All flaming about who's capable of reading the F Manual aside, what you are trying to do is end up with one big compressed file split over n floppies. All it takes is one bit to flip and your entire archive is dead. Remember, compress has no error correction. At least around here, we find floppies to be notoriously unreliable, and compress is most unforgiving. > Better compression be might be achieved by copying the entire heriarchy > (using cpio or tar), compressing the individual files, and then tarring the > shadow heirarchy. Even if the compress step were done as part of the > heariarchy copy, using a script with a loop in it, you need hard disk space > for the whole compressed heirarchy. (This also has the advantage that the > files on the diskette will be listable using "tar t" or "cpio -t".) > > If you need multiple volumes and don't have the hard disk space for a copy, > [ valuable shell script solution deleted ] A much better way to go. Don't forget that either compress or tar can suffer errors, but you can recover from tar errors. dd off the disk and hand patch or extract the tar file. Nothing will help you recover from even a single bit flip in compress. This way means you'll only lose the single compressed file with the error. > There must be better ways to get floppies with compressed archives. > I haven't used it, but perhaps "zoo" is what you want. I think what's really needed is a better tar, with error *correction* built in (CRC or the like). Maybe someone could graft in a compression option that was specifically designed to be used with error correction. True it would cost you some space, but it would be worth it. See the discussion in comp.sources.d. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
abcscnge@csuna.UUCP (Scott "The Pseudo-Hacker" Neugroschl) (05/04/88)
In article <100@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes: >> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: >> ... >> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - > >this must be an april's fools day joke of some kind. the person (jay libove) >who posted the original article has made too many mistakes for this to be >simple stupidity. > >first off, last time i checked there was no 96 tpi 9 sector device. the >only 96 tpi device was 15 sectored. > > [deleted] > >i suppose the correct response now would be `RTFM'. FLAME ON!!!! I don't normally respond to idiocy like this, but this deserves special treatement. John, Why dont YOU `RTFM'? First of all, it should be obvious from the cfk ... 720 that he is writing to a 3.5 in floppy. 3.5 inch floppies are ^^^ in fact 96tpi 9 sectors (720K), or 96tpi 18sectors (1.44M). So get of your F***ING high horse and follow your own advice!!!!!!! FLAME OFF!!! Granted that Jay's tar command line is incorrect. If it wasn't he wouldn't be asking for help. But (possibly) novice programmers and novice *NIX hacks can't always `RTFM'. The *NIX manuals are not exactly known for clarity. As a matter of fact, I consider myself a valuable employee where I work BECAUSE I can decipher the *NIX manuals. Maybe Jay did read the manual, and that's how he got that command line through a (probably very understandable) misinterpretation. Jay, I'm not sure how to do what you want (no manuals handy), but the "tar cfk /dev/rfd096ds9 720 -" part should not have the "-" in it. Tar is getting confused, as "-" is the argument of the "f", as is the /dev/rfd096ds9. Can anybody who doesn't have their head up their rear, and who does have the manuals help Jay? -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!ihnp4!csun!csuna!abcscnge -- "They also surf who stand on waves" -- Disclaimers? We don't need no stinking disclaimers!!!
romwa@gpu.utcs.toronto.edu (Mark Dornfeld) (05/08/88)
In article <196@ists> mike@ists (Mike Clarkson) writes: >In article <508@holos0.UUCP>, lbr@holos0.UUCP (Len Reed) writes: >> in article <100@pigs.UUCP>, haugj@pigs.UUCP (John F. Haugh II) says: >> > >> >> In article <8WQW5Ky00Vs8MSNUQN@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: >> >> | Hi. I'm running SCO Xenix SysV/286 v2.2.1 on an IBM PC/AT clone and >> >> | I am having a bit of a problem with "tar". >> >> | I want to tar off a filesystem as: >> >> | >> >> | % tar cf - /pathname | compress | tar cfk /dev/rfd096ds9 720 - > >You don't really want to do this (trust me I know :-). All flaming >about who's capable of reading the F Manual aside, what you are trying >to do is end up with one big compressed file split over n floppies. All >it takes is one bit to flip and your entire archive is dead. Remember, >compress has no error correction. At least around here, we find >floppies to be notoriously unreliable, and compress is most unforgiving. I experimented with compressing tar backups on disk and sending them to another system via uucp for backup. In the end I gave up because of frequent "directory checksum" errors from tar. (Xenix 286 2.2.2). Mike, I agree with the unreliability of this approach. However, Jay's problem is still there. I found cpio to be extremely reliable and the compression worked very well too, but in the end I gave up on the compression and just send the cpio file over to the backup system. >> There must be better ways to get floppies with compressed archives. >> I haven't used it, but perhaps "zoo" is what you want. > >I think what's really needed is a better tar, with error *correction* >built in (CRC or the like). Maybe someone could graft in a compression >option that was specifically designed to be used with error correction. >True it would cost you some space, but it would be worth it. >See the discussion in comp.sources.d. There is an "improved" version of tar available from a third (fourth??) party called "ctar" which has file compression as an option. .....damn, the reference is at the office. Please mail to me, and I'll send the reference out if anyone wants it. Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu