Conference hydra::amiga_v1

    If we're looking for suggestions archive schemes, mine DEFINITELY goes 
    with the directory/arc scheme that TAPE has now.  Each Fred Fish disk 
    is a directory (named FFnnn) which contains .ARC files of each of the
    sets of software on that disk.  This gives you the welcome advantage
    of being able to copy down only those files that you want from a
    Fisk Disk.  (C'mon, how many of you guys actually want ALL the programs
    on a given FF disk?)
   

    					John

    The ARC/directory scheme now used on TAPE:: is OK, but could stand
    some cleaning up.  Currently one unpacks the EXECUTE.ME file, which
    when executed does something like...
    
    	for each file
    		Unarc the file as ARCFILE.xxx
    		copy the file to its real directory and name
    		delete ARCFILE.xxx
    
    On a 512K, floppy-based machine this results in far too much disk
    grinding.  A far better procedure would be:
    
    	while still files in archive
    		Unarc next 100K or so of ARCFILE.xxx files
    		If already on destination device
    			rename the files
    		else
    			copy the files to destination directory/name
    			delete ARCFILE.xxx
    		endif
    
    Or better yet, use ZOO instead of ARC to preserve filenames and
    directory structure, and avoid this whole extract/rename business.
    
    I think it's also important to include the information files at
    the top level, because I, for one, _do_ keep some entire Fish disks.
    
    As an alternative, WARPing a Fish Disk in four sections would be
    good.  I say four sections ("40 tracks" in WARP terminology), because
    then each section is guaranteed to fit on a 360K PC diskette, handy
    for us "sneakernet" users.
    
    WARP, which uses compression, has superseded TRACKER, which doesn't.
    
    Now, before somebody thinks this is being too picky, let me finally
    suggest that the archive format should be whatever the volunteer
    archivers are willing to do.  Marco, you have set an interesting
    challenge in your request for an automated procedure.

    I personally would prefer the disks complete (either ZOO or WARP).
    If someone doesn't want everything, they can always delet what they
    don't want.
    
    Anyway, you can store them on NORSE. If you decide to use NORSE,
    I'll give you access to a new FF area
    
    Martin

    One big plus for ZOO over Warp is that we have a zoo which runs
    on VMS.  With Warp you've got to download the whole file whether
    you want everything or not.
    
    - steve

I'd prefer to see them in an Archive rather than a Warp.  What is the advantage
of ZOO over ARC?  I have been running on floppies and only had ARC (Except, (he
says brimming with joy and anticpation!) that Thurday I get my harddrive and
the problem of space becomes moot! :-) :-) :-) (note the exuding happiness.))
and haven't used zoo or warp.

Which brings up another point, how does a Warp affect a harddrive?  Does one
have to download entire disk, warp it to floppy and then pilage what they want?
Individual archives seems better to me.

George

    Re: .5
    
    ZOO preserves filenames and directory trees -- you can unzoo and
    recreate a whole file structure.  ARC, on the other hand, forces
    filenames into MSDOS format.  If you look at the FF arc-files on
    TAPE::, you will see that they are all structured with an EXECUTE.ME
    file and a bunch of files named something like ARCFILE.xxx.  The
    EXECUTE.ME file creates subdirectories and renames files properly.
    So ZOO does automatically what is presently done by ARC plus at
    least two utilities.
    
    Compression performance of both programs is about the same.  Both
    are available on VAX/VMS, Amiga and any number of other machines.
    
    Warp only uncompresses to drive DF0:, so, yes, you have to reconstruct
    the entire disk before pulling individual files.

    
    
    	TAPE:: will be happy to supply all the disk space you want as
    well as an account on the system.
    
    
    	I ARCed and uploaded all the FF disks that area on TAPE now.
    When I did this ZOO was now available. I have programs written
    in C that take FF disks and creates the execute.me files. It also
    creates execute files to ARC the files. This was the best system
    possible at the time.
    	If I were to start uploading again I would use ZOO. ZOO supports
    the file structure as well as AMIGA file names. It also has a version
    the works on VAXs to allow you to look at text files before down-load.
    This saves everyone time.
    	Tracker and warp are the worst way possible to pack files. These
    programs are very hard to use on small systems ( one drive, 512K).
    They require people to down-load entire disks just to see if they
    want anything. It also requires the entire disk to be down-loaded
    for one program. It 1200 or 2400 baud this is a long time.
    
    
    	I am willing to supply space, my old programs, or write new
    tools to help.
    
    
    		Steve Peters
    

    Now that I know, I'll vote for ZOO (what does it stand for, anyway?)
    and a quick question is... looking at the execute.me's, etc. usually
    you can specify a root.  Hence, cleanliness-freaks (like me!) could
    put all games under a /games directory on thier harddrive (only one
    day away now! :-) :-) :-)).  Does ZOO allow this replacement?  Or 
    does it demand that the structure recreate identical to the original
    (given possible change in device?)?  Inquiring minds want to know.
    
    Anyway, my vote is for Zoo archives, and I want to express a simple
    user's thanks for the people at TAPE::, NORSE::, Paul, Ed, and all the
    other people is with Amiga file repository's.  Great job, nice service,
    and all that rot!  Just thought it should be said...
    
    George
    

    First, Steve Peters and others deserve a lot of credit for uploading
    a whole bunch of Fish disks up 'til now.
    
    Now, re: .8
    
    > (Paraphrased) does ZOO allow you to specify a root directory?
    
    Yes, but not in the same way as the EXECUTE.ME scheme.  Using zoo,
    you would do something like the following...
    
    		cd dh0:destination_dir
    		zoo x df1:source_archive
    
    In other words, get into the destination directory and extract from
    the ZOO archive in some other source directory.   There's also an
    option to unpack all files to the current directory, i.e. ignore
    the directory part of the stored filenames.
    
    For the Fish disks, this is somewhat problematic.  Fred Fish structures
    his disks so that each separate title is in its own directory. 
    Some of the more extensive packages have subdirectories, so you
    could not just unpack to the current (say "games") directory.  For
    a complicated structure on a Fish disk, you would wind up doing
    something like...
    
    		cd dh0: 
    		zoo x df1:foo_archive 
    			[now you have files in /foo, /foo/src, etc.]
    		rename /foo/#? /games 
    			[on shaky ground here... may have to do
    			some steps to make sure whole directory 
    			structure gets moved] 
    		delete foo
    
    Hmmm, my CLI knowledge is pretty weak...  Anyway, there should be
    a simple procedure to rename the files properly.  Looking at the
    Enhancer 1.3 manual that came with the 1.3 disks, it should be possible
    to create a little script that LISTs all the filenames in the tree
    to a temporary file, then RENAMEs the list from the temporary file.
    
    However, I usually find that really complicated packages are best
    left alone, while games and small utilities can be moved around
    easily with Diskman, Zippy or another favorite file maintenance
    utility.
    
    Just speculating,
    Wes

    Assuming RENAME doesn't retain directory structure, does any one have a
    simple "mvdir" command that moves files (and subdiretories) around the
    trees?  [I could do it with Tar, but I'm not running AmigaUnix :-)]...
    
    George
    

    I could be wrong, but I believe rename works fine with directories.
    
    -steve

I seem to remember getting into trouble with a directory rename.

I was in a directory, which was the parent of the one I wanted to rename:

	a
	  b
	    --files in b--

I was in a. I typed  1> rename b c  to rename the directory "b" to "c". Well,
it renamed the *files* in b, not the directory.

I had to do something like  1> rename /b /c

or get one more level up (1> cd /) then type 1> rename a/b a/c


John

    IMHO, I would prefer to saee ZOO files due to the fact that they
    retain all AMIGA file info, and would allow someone to pluck a file
    out without having to see what ARCFILE.nnn is.  My second choice
    would be ARC, as I have a harddisk and would not want to have to
    unpack to floppies.  (I need all my blank floppies for HD backup
    :-)).
    
    If it was possible to UNWARP to RAD:, it wouldn't be so bad.

Re: .12

The AmigaDOS rename command does do what you want.

My theories as to what happened to you:

	You used someone else's rename command (ARP?).

	You use a shell that has a builtin rename command that
	doesn't act like the AmigaDOS rename.

	You were using 1.3 and you typed "ren" instead of "rename".
	The 1.3 shell from Commodore has a startup file that creates
	a wildcard rename called "ren".

	You typed copy instead of rename.

	Alea jacta est !
	The first ( experimental ) Fish Disk of the new repository 
	should be available soon. Steve Peters has offered to put it on

		TAPE::

	I have accepted the offer. After all HE started to share the FF
	long ago !
	I have forwarded him instructions on were to pick the FF from.
	Unfortunately the process is manual at the moment so it will 
	take time. 

	The first FF is No. 158. This has been my personal choice ( any
	point is good to start ! ) due to it's contents that I find very
	interesting.
	The chosen format is :     ZOO 
	I've used Z00 v2.0. There is a file for each directory plus one
	which contains all the .info, readme, contents etc.... This is named
	FF158.zoo.

	To unzoo it , follow this simple procedure.
	Suppose the zoo files have been down loaded to your FOO:DIR1/...
	You want to create the full FF158 on DF1.

	> relabel df1: "AmigaLibDisk 158"	
	> cd df1:
	> zoo e// foo:dir1/ff158
	> zoo e// foo:dir1/diskx
	...
	> zoo e// foo:dir1/virusx

	In case you just want to try one piece....

	> cd RAM:			( or better VD0: )
	> zoo e// foo:dir/diskx

	These procedures will create the full structure ( including 
	directories).
	
	ATTENTION !!

	ZOO has a bug ( I think ! ) After creating the structures the
	it doesn't release the directories lock, so you cannot delete
	the directories nor get rid of the disk icon. These are the
	only inconvenient. If these are caused by my misuse of ZOO
	please let me know.

	Next FF will be No. 163 ( due to ReadmeMASTER, a FISH DISK 
	automated index for FF 1-154 ). I have no preference after that.
	By default I will start from FF172 down. If you have a special need,
	please send mail to VENERE::ZABOT. 

	The exact location from where to fish ( :-) will be posted soon
	( I hope ) by Steve.

	I think it's also important that someone gives a pointer to where
	is available ZOO.EXE ( VMS version).

	If someone has the FF110 and FF145 please post them ( these are the
	only two I'm missing).

	Good fishing.
	marco

re .14

>	You were using 1.3 and you typed "ren" instead of "rename".
>	The 1.3 shell from Commodore has a startup file that creates
>	a wildcard rename called "ren".


Thats right. But I think I have an "Alias ren rename" in my Shell-Startup

I could be just suffering from terminal delusion

John

    To assist in doing a full disk zoo, I came across a program called
    FNAMS which will produce a file of Filenames to be used as the stdinput
    for zoo with the I option, it also comes with a companion zooall
    execute file which will create a zoo file of all files from the
    current directory on down.  After a little editing of the execute
    file I was able to CD DF0: (ff170 disk) and use 
    Execute tools:zooall ram:ff170.zoo  to create the complete zoo.
    
    Seems to work but only use will tell.
    
    You can find FNAMS22.ZOO in cgou01::amnew:
    
    wayne
    

    FF150 and FF151 are on TAPE::USER1:[upload]
    in wrp format
    Phil
    

    
    
    FF150 and FF151 have been moved to TAPE::USER1:[AMIGA.FF150] and
    TAPE::USER1:[AMIGA.FF151]
    
    
    		Steve
    

	I've just started to upload to TAPE::USER1:[UPLOAD]	
	the FF163. With it , I've also put a demo of CALIGARI !!

	This is composed of three files:
		README.
		CALIG.ARC 
		CALDATA.ARC
	Please, Steve , move this file where they belong to a put a 
	notice on Amiga Notesfile ( I cannot reach it ).
	The README. file has all the info to set up the CALIGARI info.
	( I'm sure you remeber that CALIGARI is a log time ago announced
	3D rendering/animator program. It's really nice).

	Ciao e Buon Weekend
	marco

	Ok. I admit it! I've been late in uploading FF as promised
	( other have beaten me).

	What I'd like to achieve is a COMMON method for setting the
	repository up.  As most people agree, I think the best way 
	is to use ZOO, but not just plain ZOO, but structured in the
	following way:


	Directory TAPE::USER1:[AMIGA.FF163]

	BANKN.ZOO;1             326  18-FEB-1989 10:14:07.00
	FF163.ZOO;1              65  18-FEB-1989 13:00:21.00
	FIVEINLIN.ZOO;1          31  18-FEB-1989 10:47:43.00
	MACHII.ZOO;1             74  18-FEB-1989 10:50:49.00
	MEMTRACE.ZOO;1            8  18-FEB-1989 10:58:15.00
	PCPATCH.ZOO;1            18  18-FEB-1989 10:59:03.00
	READMEMAS.ZOO;1         344  18-FEB-1989 11:00:56.00
	VIEW.ZOO;1               17  18-FEB-1989 11:35:17.00

	As you can see there is a file  FF163.zoo which contains
	all the files at first level ( *.info, Documents etc..)
	and the C directory.

	The other files are one for each `product'. This makes 
	simple to someone looking for just, let say, BANKN pick
	it without caring for the rest.

	To ZOO as FF this way ( waiting for a better procedure )
	I do as follow:

	suppose FF163 is on DF0:
		you're using Dillon SHELL

	> cd vd0:			( or where you prefer ! )
	> zoo a ff163 df0:*
	> zoo a ff163 df0:c/.../*	this gives you ff163.zoo

	then for each product:

	> zoo a BANKN df0:BANKN/.../*	this gives you BANKN.zoo

	Now you have the full set of files for one FF.
	Upload it to VAX. Transmit to TAPE:USER1:[UPLOAD] and
	Steve as to pick them in the bunch and move to the right
	place.

	marco


PS.	BTW. An advantage in using ZOO is that is should be available
	on VMS. Unfortunately someone ( thank you ) has uploaded it
	( VMSZOO.ZOO ) but it's zoo'd so it requires ZOO to unZOO it,
	( chicken and egg syndrome ! ) ...

	Please could you post it in EXE format ?

>    PS.	BTW. An advantage in using ZOO is that is should be available
>	on VMS. Unfortunately someone ( thank you ) has uploaded it
>	( VMSZOO.ZOO ) but it's zoo'd so it requires ZOO to unZOO it,
>	( chicken and egg syndrome ! ) ...
    
    Oops.  I did that and will upload the executable.  The archive also
    includes FIZ, sort of a Disksalv for Zoo archives, and BILF, an
    equivalent to CVTARC.
    
    Wes

MDKCSW::DUA2:[DAVIS.AMIGA.TOOLS] has ZOO and BILF.

...richard

    
    	VMSZOO is now in
    
    	TAPE::USER1:[AMIGA.TOOLS]VMSZOO.EXE
    
    		Steve
    

    reply  .21>
    
    Could you undo the protection on the Caligari demo, ppppppplease??? 
    
    -Todd
    

    
    
    	The Caligari demo is in
    
    	TAPE::[AMIGA.ARC.CALIGARI]*.*
    
    	And the protection has been fixed.
    
    	Steve
    

    
    
    	New Fish ---
    
    	FF disks 189,191,192,193,194
    
    	are now in TAPE::USER1:[AMIGA.FFxxx]
    
    		Steve Peters
    

    re .29
    
    Now that 11 days have passed I can't hold back no longer....
    
    WHERE IS FF 190 ????
    
    If I recall correctly some of the nethack parts are on this one...
    Anybody?
    
    Thanks,
    	<CB>
    

    I have been hoping for a message about FF190.
    
    I also want to thank Steve Peters, for his effort in uploading the
    fish disks.  I am sure there are many of us that are getting the
    disks off the net.  We definitly appreciate your work.
    
    The decision to use zoo for the fish disks was an excellent choice.

    FF190 hasn't been uploaded by me due to my source having received
    2 copies of ff189,  Fred will be sending us ff190 soon.  We received
    FF195-200 this past weekend, so hopefully I will have a copy later
    this week to upload.  I thought zoo'ing was the best approach since
    not everybody wants to download the entire disk and everybody has
    VMS Zoo on their system (right).
    
    Any votes for working back through the older disks?
    
    wayne
    

    
    re .31
    
    Just to  set the record straight, Wayne Oakley has uploaded most of
    the Fish disks  since 170 or so.  As soon as he gets them from the
    local club he Zoo's them and uploads.  Not to take away any of the
    glory from Steve, the space on TAPE:: is very much appreciated.
    
        Regards....   Clint

    Well, thanks for setting the record straight.  It good to know who
    is responsible for what.  So thanks again, to all those responsible
    for the fish disk uploads.
    
    Just a side question though.  Are these uploads done by modem or
    do you have the advantage of an amiga in the office?  Because, even
    with Ymodem at 2400, its takes a long time for me to download.

    Uploading Fish Disk is one of the best job done from you all here
    in this note file.I appreciate it very much, as it is long to get
    them here in Europe by normal distribution.Thanx a lot.
    I also find zooing them is THE good choice
    
    Phil

	I vote for working through the backlog, but there again I won't be 
	doing the work - but would appreciate the results.

	DaveB

    All of the uploads which I have done have been over the modem at
    1200 or 2400 (the 2400 is not on a direct in line, so we occasionally
    forward another number for the night).  I have a procedure which
    will read a disk and zoo the whole thing maintaining the directory
    structure information.  So the whole procedure is relatively painless,
    just time consuming, but since I have a second phone line for the
    amiga I just leave it run.
    
    I will start working down through the fish disks as time is available.
    
    wayne
    

	I don't use the PD directories yet (my amiga is in storage
	pending our house move) but I have a suggestion to make...

	How about renaming the FF directories on TAPE:: to be FFnnn.DIR?
	This way, disk FF005 would appear before disk FF100 in the directory
	listing, making it easier to locate a specific disk.

	(Can't wait to get my hands on some of that stuff).

Keith

    re .37
    
    I have been thinking about a second phone line, since I got my Amiga
    last November.  I still must consider the phone to be a limited
    resource, with 2 kids in the family.  A second phone will probably
    be a must when they hit the teens.
    
    
    re .38
    
    I agree that would certainly make a directory more readable.  But
    if all the disks are now a single .zoo file, why not also get rid
    of the multiple directories.  Just put all the new .zoo files in
    a single FREDFISH directory.
    

    I've starting downloading some of the excellent PD software from TAPE::
    and I've got a minor problem using the BUILD procedure.  To extract the
    archive onto DF1:, I put the unZOOed files (.ARC, BUILD, LIST, etc.)
    on DF1: and then type 

        > CD DF1:

    and 

        > EXECUTE BUILD

    This returns a message "Extracting XXXX on", and then extracts the file.
    Two problems:

        1) The BUILD script starts with a ".key <DEV>" command, and is
    supposed to say "Extracting XXXX on DF1:".  Why doesn't this work?  Is
    there a parameter to BUILD that specifies the destination?

        2) I get all the appropriate sub-directories, but I don't get a
    drawer icon to let me access the sub-directories from Workbench.  I
    created one manually by copying and renaming the EMPTY drawer.  Is there
    a better way?  Should BUILD have done this automatically?

        This happened to me when downloading AMOEBA, from FF120.  BTW, this is a
    GREAT clone of Space Invaders!  Check it out!

        One more problem:  When I unZOO some of the later FF disks, all the
    icons come out in a total mess (on top of each other, etc.).  I can
    use CLEANUP to fix this--is there a better way?  Also, most of the doc
    files expect sys:c/less as their default tool.  Do most people put
    "less" in their sys:c directory, or do people change the default tool of
    the doc files?  I first noticed this on FF173.


    Thanks for the help,
    Sam

    

>    archive onto DF1:, I put the unZOOed files (.ARC, BUILD, LIST, etc.)
>    on DF1: and then type 


For the arc files built this way (have a BUILD, LIST, and FILExx files),
all you need to do is extract the BUILD,then execute it:

(on new formatted floppy in DF1: if you want)

> copy xxx.arc df1:			xxx.arc is the arc file (really!)
> cd df1:
> arc -e xxx build
> execute build
or can be:
> execute build df1:


>        2) I get all the appropriate sub-directories, but I don't get a
>    drawer icon to let me access the sub-directories from Workbench.  I
>    created one manually by copying and renaming the EMPTY drawer.  Is there
>    a better way?  Should BUILD have done this automatically?

I don't remember, but I don't think build makes the top level drawer icon.
You can just drag EMPTY from the Workbench floppy to this new floppy and then
RELABEL it to the top level directory name.



>        One more problem:  When I unZOO some of the later FF disks, all the
>    icons come out in a total mess (on top of each other, etc.).  I can
>    use CLEANUP to fix this--is there a better way?  Also, most of the doc

Either that or move them all where you want, then hold down the SHIFT key as
you click ONCE on each icon. This will select them all. Now select SNAPSHOT
from the Workbench menu and it will save thier positions.

If you resized the window thier in, you need to get back to it's parent
(another drawer or a disk), select only it, then do a SNAPSHOT. This will
save it's size/position.


>    files expect sys:c/less as their default tool.  Do most people put
>    "less" in their sys:c directory, or do people change the default tool of
>    the doc files?  I first noticed this on FF173.

I keep a copy of MORE in my SYS:Utilities/ area. Then change all default
tools as I run across them to point there. In fact, in my startup-sequence
I have a ASSIGN UTILS: SYS:Utilities/  so all I need to specify is
UTILS:MORE.


John

Thanks for the help, John!

I'll play some more and let you know the results...

Sam