hv@chyde.uwasa.fi (Harri Valkama LAKE) (06/30/89)
I don't know how widely ZOO is used in Atari ST world but I think that we should consider to change our "manners" in such a way that comp.binaries.atari.st could use ONLY ZOO as the one and only archiving pgm instead of ARC. This probably wakes up a great polemic but I think this what I'm suggesting is the only resonable thing to do. Because comp.binaries.ibm.pc had already done this and many sites already have ZOO in UNIX or VMS machines via which these binaries come. And then there are people (like me) who also must use PC/XT/AT to transmit these binaries to Atari where they belong. So don't overlook this suggestion. I know that there are many of you who don't see any reason why we should do this. We here in Vaasa, Finland (chyde.uwasa.fi) have ZOO sources available fot anonymous ftp and Oulu, Finland have ZOO binaries for Atari ST. So this change is possible. -- Harri Valkama : email: hv@chyde.uwasa.fi (internet) Computer Centre, University of Vaasa : valkama@finfun (bitnet) P.O.BOX 700 : voice: +358 61 248426 SF-65101 VAASA FINLAND : site: 128.214.12.3
silvert@cs.dal.ca (Bill Silvert) (07/01/89)
In article <619@chyde.uwasa.fi> hv@chyde.uwasa.fi (Harri Valkama LAKE) writes: >I don't know how widely ZOO is used in Atari ST world but I >think that we should consider to change our "manners" in such >a way that comp.binaries.atari.st could use ONLY ZOO as the >one and only archiving pgm instead of ARC. I would approach this with caution. Archivers have to work on many different machines, and extractors have to be widely available. First we have to ensure that all submitters have zoo and all potential users have either zoo or booz. I haven't yet seen self-extracting archives for the ST such as those for PC zoo archives, but these could be dangerous (Trojans could be included). We also have to be sure that the archives can be read on other machines, since sysops may need to examine ST archives on BBS's run on other machines. For example, I run a BBS on a Unix system, and I had major problems compiling ZOO. Also, I have had trouble transferring ZOO archives, and I suspect the problem is that some protocols don't recognize ZOO magic. Using ZMDM I was unable to download some ZOO archives with Ymodem, although the same programs transferred it OK with Zmodem. Until these problems are cleared up, I see no need to discard the old reliable ARC. -- Bill Silvert, Habitat Ecology Division. Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2 UUCP: ...!{uunet,watmath}!dalcs!biomel!bill Internet: biomel@cs.dal.CA BITNET: bs%dalcs@dalac.BITNET
usenet@cps3xx.UUCP (Usenet file owner) (07/01/89)
in article <619@chyde.uwasa.fi>, hv@chyde.uwasa.fi (Harri Valkama LAKE) says: > > I don't know how widely ZOO is used in Atari ST world but I > think that we should consider to change our "manners" in such > a way that comp.binaries.atari.st could use ONLY ZOO as the > one and only archiving pgm instead of ARC. I'm for this, but wasn't there mention of a bug fix with ZOO and a shell for use with the Atari ST version? I have been waiting for that for quite a while now and I would like any information on it's progress. Does anyone know about this? /-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-\ | "It's only wafer thin." | Lonnie Warpup | Bitnet: 21585XEN@MSU | < -Monty Python's... - - - - - - - - UseNet: uunet!frith!mann > | -"The Meaning Of Life" Internet: mann@frith.egr.msu.edu | \-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-/
rosenkra@hall.cray.com (Bill Rosenkranz) (07/02/89)
In article <1989Jul1.134205.14628@cs.dal.ca> bill@biomel.UUCP writes: =In article <619@chyde.uwasa.fi> hv@chyde.uwasa.fi (Harri Valkama LAKE) writes: =>I don't know how widely ZOO is used in Atari ST world but I =>think that we should consider to change our "manners" in such =>a way that comp.binaries.atari.st could use ONLY ZOO as the =>one and only archiving pgm instead of ARC. = =I would approach this with caution. Archivers have to work on many =different machines, and extractors have to be widely available. = =First we have to ensure that all submitters have zoo and all =potential users have either zoo or booz. I haven't yet seen =self-extracting archives for the ST such as those for PC zoo archives, =but these could be dangerous (Trojans could be included). ^^^^^^^^^^^^^^^^^^^^^^^^^^ exactly! i for one am EXTREMELY cautious about running programs which do not come with source. the though of self extracting achives should make you equally cautious. arc has been serving everyone on the planet for so long with such good success that minor incremental features do not seem warranted. if u want to preserve a directory structure, consider arcing a tar file. GNU tar has been ported to the ST and is widely available, at least on unix hosts. changes to very well established procedures should be very well thought out. =We also have to be sure that the archives can be read on other =machines, since sysops may need to examine ST archives on BBS's =run on other machines. For example, I run a BBS on a Unix system, and =I had major problems compiling ZOO. not everyone has FTP access, so before a switch is made, any new scheme should be made available long (say 6 months) before it is adopted. =Also, I have had trouble transferring ZOO archives, and I suspect the =problem is that some protocols don't recognize ZOO magic. Using ZMDM =I was unable to download some ZOO archives with Ymodem, although the =same programs transferred it OK with Zmodem. = =Until these problems are cleared up, I see no need to discard the old =reliable ARC. agreed... besides {x,y,z}modem, kermit should be thoroughly tested, too. =Bill Silvert, Habitat Ecology Division. -bill rosenkra@boston.cray.com
martin@lakesys.UUCP (Martin Wiedmeyer) (07/02/89)
In article <1989Jul1.134205.14628@cs.dal.ca> bill@biomel.UUCP writes: [stuff deleted] >Also, I have had trouble transferring ZOO archives, and I suspect the >problem is that some protocols don't recognize ZOO magic. Using ZMDM >I was unable to download some ZOO archives with Ymodem, although the >same programs transferred it OK with Zmodem. > I have found that rz/sz doesn't recognize a .zoo file as a binary. I have to force the binary mode with the -[bB] switch to either rz or sz. Then all goes fine. ZOO does make smaller archives, but I must agree that we must make certian that the distribution of the ZOO utilities is such that noone will be without it. Let's stick with ARC for now.... On another tack : The netlib archives here at lakesys apparently will not be up again. Thanks to all who contributed and used netlib@lakesys. It was a pleasure being of service to the net ST community. Marty Wiedmeyer
f-leoe@IFI.UIO.NO (Lars-Erik 0sterud) (07/03/89)
I just got a dutch packer that compresses program-files down to 60 - 75% og their original size, and the really nice thing is that they still are executable AND that there is no time delay for decompressing !!! I send it to comp-binaries, but they want be out for a while..... Lars-Erik 0sterud / Summer & Christmas: / leoe@ifi.uio.no / f-leoe@ifi.uio.no / ____________________/ _______________________/
ljdickey@water.waterloo.edu (Lee Dickey) (07/04/89)
In article <619@chyde.uwasa.fi> hv@chyde.uwasa.fi (Harri Valkama LAKE) writes: >I don't know how widely ZOO is used in Atari ST world but I >think that we should consider to change our "manners" in such >a way that comp.binaries.atari.st could use ONLY ZOO as the >one and only archiving pgm instead of ARC. ZOO is not widely used (yet). It is new, and has been distributed. Have you tested or used it extensively on the ST? Are the sources freely available? ARC is also available on the PC and on the UNIX system, so that argument alone that other systems use ZOO does not carry much weight with me, and that alone is not enough to persuade me to switch. I looked at the documenatation that is in our manual on the UNIX system here, and the explanations look HORRENDOUS! Two levels of commands do not help, awkward syntax for simple semantic do not help, and I saw a plea for help from someone who had simply misplaced a punctuation mark. That says to me not carefull planning. On the plus side, I think that the big advantage of ZOO is that one can store directory path information along with the file. Convince me please! What other feature do you find that is compelling enough to convince the world to give up a reliable piece of software in favour of a new one that probably still has bugs in it. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
klute%trillian.irb@unido.uucp (Rainer Klute) (07/06/89)
In article <2492@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >In article <619@chyde.uwasa.fi> hv@chyde.uwasa.fi (Harri Valkama LAKE) writes: >>I don't know how widely ZOO is used in Atari ST world but I >>think that we should consider to change our "manners" in such >>a way that comp.binaries.atari.st could use ONLY ZOO as the >>one and only archiving pgm instead of ARC. > >On the plus side, I think that the big advantage of ZOO is that >one can store directory path information along with the file. And this feature is a real time saver both for the submitter and for the receiver of a software package which is structured in several (possibly nested) directories. An extreme example is DVIST with a lot of font directories. In the last distribution it was still packed with ARC: Each directory is packed as an ARC file, and nested directories are ARC files contained in other ARC files. Those of you who have unpacked DVIST know how much time they needed. Now consider Zoo: You issue *one* command and Zoo does all that time consuming stuff for you - and of course much faster. Surely the above only applies to software packages with a directory structure. Most software however comes with a few files on the same directory level. In this case ARC is fully sufficient and there is no need to change to Zoo. I do not see any obstacle to use *both* programs. Like ARC Zoo was distributed on comp.binaries.atari.st and is available in archives so everyone should already have it for his ST or should at least be able to get it. On a related topic: In my (spare) free time I am working on ARCGSH V2.0. The most important change to the current version 1.4 will be that (in addition to ARC) a user-friendly interface to Zoo is supported. I am also planning to support archiving and unarchiving shell archives (SHAR). There are also some minor changes to improve the usability of the program. I am thinking about making ARCGSH a shareware program. Therefore some questions: Would *you* like to use ARCGSH V2.0 or do you think V1.4 is sufficient (if you use it at all)? Would *you* be willing to pay some $$ for ARCGSH V2.0? Rainer Klute ---- klute@trillian.irb.informatik.uni-dortmund.de Univ. Dortmund, IRB |)|/ klute@unido.uucp, klute@unido.bitnet Postfach 500500 |\|\ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 ---- Tel.: +49 231 7554663
janhen@kunivv1.sci.kun.nl (Jan Hendrikx) (07/06/89)
In article <2492@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >In article <619@chyde.uwasa.fi> hv@chyde.uwasa.fi (Harri Valkama LAKE) writes: >>I don't know how widely ZOO is used in Atari ST world but I >>think that we should consider to change our "manners" in such >>a way that comp.binaries.atari.st could use ONLY ZOO as the >>one and only archiving pgm instead of ARC. > >ZOO is not widely used (yet). It is new, and has been distributed. >Have you tested or used it extensively on the ST? Are the sources >freely available? Zoo *IS* widely used in the Amiga community. It is very reliable. And the sources are freely available. In fact, on the Amiga sources/binaries groups, Zoo has been already *the* archiver of choice for ages. >I looked at the documenatation that is in our manual on the UNIX >system here, and the explanations look HORRENDOUS! Two levels of >commands do not help, awkward syntax for simple semantic do not help, >and I saw a plea for help from someone who had simply misplaced >a punctuation mark. That says to me not carefull planning. You mean you don't like the built-in help? And you think Arc is more intuitive to use (if you want the same thing)? And if you really find the 'expert' commands too complicated, you can use the 'novice' commands instead, which are sufficient most of the time. This is the built-in help: Zoo archiver, Version 2.01 (1988/08/25 12:43:57) (C) Copyright 1988 Rahul Dhesi -- Noncommercial use permitted Usage: zoo {acDeglLPTuUvx}[aAcCdEfInmMNoOpPqu1:/.@n] archive file ("zoo h" for help) Choose a command from within {} and zero or more modifiers from within []. E.g.: `zoo a save /bin/*' will archive all files in /bin into save.zoo. (Please see the user manual for a complete description of commands.) Commands in {} mean: |Modifiers in [] mean: a add files | a show archive name(s) in listing c update comments | A apply g or c to archive D delete stored files | c add/list comments e,x extract files | d extract/list deleted files too g adj. gen. limit/count | dd extract/list only deleted files l,L,v,V list filenames | E erase backup after packing P pack archive | f fast add (no compression) or list T fix archive datestamp | M move when adding (erase original) u add only newer files | n add only files not already in archive U undelete stored files | N send extracted data to Neverland f act as filter | c/u compress/uncompress as filter ----------------------------- O don't ask "Overwrite?" q be quiet p pipe extracted data to standard output : don't store dir names /,// extract full pathnames . pack to current dir I add filenames read from stdin C show file CRC value +/- enable/disable generations S overwrite newer files g list generation limits P pack after adding @n start extract/list at position n m list file modes OO overwrite read-only files Novice usage: zoo -cmd archive[.zoo] file... where -cmd is one of these: -add -extract -move -test -print -delete -list -update -freshen -comment >On the plus side, I think that the big advantage of ZOO is that >one can store directory path information along with the file. > >Convince me please! What other feature do you find that is compelling >enough to convince the world to give up a reliable piece of software >in favour of a new one that probably still has bugs in it. Like I said, there are no fatal bugs in Zoo that I ever knew of. But you wanted features? Well, you might like the ability to have several versions of the same file in the archive (generations). And the directory structure is something you don't want to miss once you used it. And you can have file names longer than 8+3, though that is admittedly of more use on Amiga's, Unix and other systems that normally allow such filenames. (But it shows that Arc is needlessly restricted in this area). And you can attach comments to each file separately and to the archive as a whole. > L. J. Dickey, Faculty of Mathematics, University of Waterloo.
woodside@ttidca.TTI.COM (George Woodside) (07/10/89)
In article <2492@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: ...[edited] >On the plus side, I think that the big advantage of ZOO is that >one can store directory path information along with the file. Advantages may be dis-advantages if used incorrectly. And this will be used incorrectly. While it is very handy to be able to store path names in the archives for your own backup copies, it will cause a plethora of problems as soon as the disk leaves your environment. Postings, copies of disks, backup/restore after a change to your directory structures, and other scenarios will have lots of new problems with either unwanted directories being created, or archive expansion failing when paths are not found. Like most powerful tools, this one requires great care in its use to avoid becoming the Eggplant that Ate New York. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
rosenkra@hall.cray.com (Bill Rosenkranz) (07/12/89)
---
on a related note: is it possible to have absolute paths in zoo? if so,
if someone makes a m:\... file and u don't HAVE an "m:\" disk, this could
be VERY annoying...
nothing is more frustrating than getting a tar tape with absolute path names
("hey, guy...maybe i DON'T have 20 MB available in /"). fortunately, there
are remedies on a unix system but this could be a problem with zoo...
-bill
rosenkra@boston.cray.com