haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) (12/07/87)
Under 4.3BSD, has anybody ever been able to add files to an existing tar tape with tar r? When we try it the tape goes around and it appears to be doing something, but then when we tar t the files are not there. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (12/10/87)
In article <1344@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) writes: > Under 4.3BSD, has anybody ever been able to add files to an existing > tar tape with tar r? When we try it the tape goes around and it > appears to be doing something, but then when we tar t the files are > not there. Script started on Wed Dec 9 09:05:18 1987 $ tar cf /dev/rmt8 /etc/motd /etc/group $ tar tf /dev/rmt8 /etc/motd /etc/group $ tar rf /dev/rmt8 /etc/passwd $ tar tf /dev/rmt8 /etc/motd /etc/group /etc/passwd $ script done on Wed Dec 9 09:05:57 1987 In answer to your question, yes, "tar r" has been used under 4.3BSD. --keith
larry@sgistl.SGI.COM (Larry Autry) (12/11/87)
In article <22121@ucbvax.BERKELEY.EDU>, bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes: > In article <1344@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) writes: > > Under 4.3BSD, has anybody ever been able to add files to an existing > > tar tape with tar r? When we try it the tape goes around and it > > appears to be doing something, but then when we tar t the files are > > not there. > On the SGI Iris 3030 'tar r' is known not to work with 1/4" tapes. However, unless you absolutely must append to the original and only tar file on the tape there is an alternate method. Using the 'mt' utility if it is available on your system, space the tape past the first tar file. Additional files can be added to the tape. This accomplished by using the non-rewind device number as the output device. If 'mt' is not available, try using 'tar t2'. example: mt fsf 1 tar cv2 . (uses /dev/rmt2 as output) mt rew and of course to retrieve; mt rew mt fsf 1 tar xv2 mt rew This can be used for cpio as well. I realize that this does not address the actual problem of appending to files. It does however solve the problem of wasting cartridge tapes by having only one file on the entire tape. disclaimer - It worked for me on my system, good luck. -- Larry Autry larry@sgistl.sgi.com or {ucbvax,sun,ames,pryamid,decwrl}!sgi!sgistl!larry
dce@mips.UUCP (David Elliott) (12/11/87)
In article <22121@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes: >In article <1344@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) writes: >> Under 4.3BSD, has anybody ever been able to add files to an existing >> tar tape with tar r? When we try it the tape goes around and it >> appears to be doing something, but then when we tar t the files are >> not there. ... >In answer to your question, yes, "tar r" has been used under >4.3BSD. My experience is that it depends on the "tape" device involved and the driver. If it is a regular file, it works. If it is a pipe, it can't. If it is a streaming tape (either QIC or 1/2"), it is generally not possible, since positioning the tape is costly. In fact, some systems (Tek 61XX, for example) want you to read and write big chunks (128K) to avoid burning out the motor, and don't supply tape record backspace. In any event, if the driver doesn't support record backspace or backward seeks, you can't do the 'r'. You need to understand that a tar tape (see tar(5)) ends with two zero blocks followed by random data. In order to do the replace, tar has to go to the end of the tape, backspace a record, rebuild the last record with the new data in place, and then continue as though it was the original 'tar' running. Sadly, no tape format for Unix has been completely successful at dealing with everything. Tar doesn't handle long file names or multiple volumes. Cpio doesn't handle volumes out of order and can't be ported easily to systems with long inode or device numbers. Dump is for filesystems. Nobody deals with adding to the end of a tape by simple concatenation. I think that whoever comes up with something to handle all of these problems and can get people to use it will deserve a lot of gratitude. -- David Elliott dce@mips.com or {ames,decwrl,prls}!mips!dce
snoopy@doghouse.gwd.tek.com (Snoopy) (12/12/87)
In article <1085@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >If it is a streaming tape (either QIC or 1/2"), it is generally not >possible, since positioning the tape is costly. In fact, some systems >(Tek 61XX, for example) want you to read and write big chunks (128K) to >avoid burning out the motor, and don't supply tape record backspace. The "burning out the motor" bit refers to the Cypher drives, which were disqualified. All production units have Wangtek drives, which don't burn out their motors. A large block size is still recommended to minimize the amount of time wasted repositioning the tape. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com Pizza. Just say yes.