mdixon@parc.xerox.com (Mike Dixon) (01/16/91)
Transfer all files whose names end in .tar or .tar.Z in binary mode,
which is set with the binary command. Executable must also be
transfered in binary mode. Actually, anything that isn't text must be
transfered in binary mode.
actually, just transfer everything in binary mode. (text mode just
gives you lf/cr conversions between unlike OS's, but for unix-to-unix
--
.mike.eps@toaster.SFSU.EDU (Eric P. Scott) (01/16/91)
For those of you without FTP access (you're missing SOOOOO much), send mail to archive-server@cc.purdue.edu with Subject: help and no message text. In article <Fe7h6#94@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > tar xf filename.tar > >Files ending with .tar.Z are compressed archives that can be unpacked >by typing > > zcat filename.tar.Z | tar xf - tar xopf is more appropriate in nearly all cases. I generally toss a "v" in there too. -=EPS=-
madler@pooh.caltech.edu (Mark Adler) (01/16/91)
eps@cs.SFSU.EDU (Eric P. Scott) believes: >> tar xopf is more appropriate in nearly all cases. I generally >> toss a "v" in there too. The "o" has no effect with "x" (it forces an old tar format when *making* tar files). The "p" option uses the modes in the tar file, which I don't think is a good idea unless you're going to always look at the modes afterwards. I hate ending up with files writable by everyone, and not noticing. Tossing a "v" in is quite useful, since you see what files tar made and where it put them. My untarz command is: zcat $1.tar.Z | tar xvf - and my tarz command is: tar covf $1.tar $1 compress $1.tar I also have untarzrm and tarzrm commands which delete the .tar.Z, or the packaged directories respectively. Note that my tarz command expects the name of a directory and will package whatever is in there, with the directory name. This makes for much cleaner untarz's, since the resulting files don't get all mixed up with whatever files are in the current directory. Mark Adler madler@pooh.caltech.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (01/16/91)
Oops! Sorry, wrong version of tar... I'm used to o on extract suppressing chown(). You're right--it's a no-op here. I really do want p, however--I've been burned far more times without it than with it. -=EPS=-
tempest@walleye.uucp (Kenneth K.F. Lui) (01/16/91)
In article <1991Jan16.034038.14804@nntp-server.caltech.edu> madler@pooh.caltech.edu (Mark Adler) writes: >The "o" has no effect with "x" (it forces an old tar format when *making* >tar files). The "p" option uses the modes in the tar file, which I don't >think is a good idea unless you're going to always look at the modes >afterwards. Here's a part of the tar man page: o On output, tar normally places information speci- [ ^^^^^^ <- note the mode, not making tar files.] fying owner and modes of directories in the archive. Former versions of tar, when encounter- ing this information will give error message of the form "<name>/: cannot create". This modifier will suppress the directory informa- tion. p This modifier says to restore files to their ori- ginal modes, ignoring the present umask(2). Setuid and sticky information will also be restored to the super-user. I find the p option very useful as it keeps the file dates upon extraction. Too bad ftp doesn't have an equivalent option for *gets and *puts, as I can never tell if two files with the same name when using their dates. Ken Ken ______________________________________________________________________________ tempest@ecst.csuchico.edu, tempest@walleye.ecst.csuchico.edu,|Kenneth K.F. Lui| tempest@sutro.sfsu.edu, tempest@wet.UUCP |________________|
tempest@walleye.uucp (Kenneth K.F. Lui) (01/16/91)
In article <1991Jan16.034038.14804@nntp-server.caltech.edu> madler@pooh.caltech.edu (Mark Adler) writes: >The "o" has no effect with "x" (it forces an old tar format when *making* >tar files). The "p" option uses the modes in the tar file, which I don't >think is a good idea unless you're going to always look at the modes >afterwards. Here's a part of the tar man page: o On output, tar normally places information speci- [ ^^^^^^ <- note the mode, not making tar files.] fying owner and modes of directories in the archive. Former versions of tar, when encounter- ing this information will give error message of the form "<name>/: cannot create". This modifier will suppress the directory informa- tion. p This modifier says to restore files to their ori- ginal modes, ignoring the present umask(2). Setuid and sticky information will also be restored to the super-user. I find the p option very useful as it keeps the file dates upon extraction. Too bad ftp doesn't have an equivalent option for *gets and *puts, as I can never tell if two files are the same on different sites when using their dates. Ken ______________________________________________________________________________ tempest@ecst.csuchico.edu, tempest@walleye.ecst.csuchico.edu,|Kenneth K.F. Lui| tempest@sutro.sfsu.edu, tempest@wet.UUCP |________________|
madler@pooh.caltech.edu (Mark Adler) (01/17/91)
In article <1991Jan16.192825.1412@csn.org!datran2> smb@csn.org!datran2 writes: >by who knows what system. If I don't use the "o" option to extract, the >original owners and groups are sometimes preserved. The uid of the owner You must be using tar as a superuser. I almost never login as root, so I had not observed this behavior before. I suppose it makes good sense though if you're restoring a file system from a tar tape. As you point out, the man page fails to mention this effect of "o" when used with "x". Mark Adler madler@pooh.caltech.edu
datran2 (01/17/91)
In article <1991Jan16.202825.14136@nntp-server.caltech.edu> madler@pooh.caltech.edu (Mark Adler) writes: >In article <1991Jan16.192825.1412@csn.org!datran2> smb@csn.org!datran2 writes: >>by who knows what system. If I don't use the "o" option to extract, the >>original owners and groups are sometimes preserved. The uid of the owner > >You must be using tar as a superuser. I almost never login as root, so I >had not observed this behavior before. I suppose it makes good sense In fact I have seen the behavior as a normal user. One recent ftp tar archive that I extracted created a subdirectory owned by a uid not defined on my system and with no write permission for group or other. tar then refused to create the remainder of the files which were to be on that subdirectory. I had to su to remove the directory, exitted from root and used tar xovf which created the directory with my own uid. This doesn't seem to occur for tar archives created from the NeXT. Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # "Badgers, we don't have no stinking badgers" # # datran2!smb@csn.org # -from Treasure of the Sierra Madre Zoo # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#