Last updated 1-August-97
HELLO!
Welcome to the University of Michigan's Macintosh Public Domain and
Shareware Archive!
This file has been created to give you an introduction to the
archive and to answer some frequently asked questions that might
be brewing in your head at this point...
WHO:
There are seven (7) archivists for the archive.
Michael Dautermann (myke@umich.edu)
Suzi Nassen Stefl (stf@umich.edu)
Scott Damask (sdamask@umich.edu)
Howard Levine (hlevine@us.itd.umich.edu)
Peter Swanson (pjswan@engin.umich.edu)
Jay Hennessey (henn@mac.archive.umich.edu)
Chris Thomas (macdude@mac.archive.umich.edu)
as well as three dudes, who were original archivists
and still serve as guidance-givers:
Robert Churchill (rjc@umich.edu)
Mike Kuniavsky (mikek@umich.edu)
Dave Koziol (koziol@umich.edu)
If you have questions about any files or regarding the archive, you
can send them to us at "questions@mac.archive.umich.edu".
Collectively, you can send a message to "comments@mac.archive.umich.edu"
and that message will reach all of us (the first person to retrieve
the message will most likely answer any question or suggestion first..)
WHAT:
The archive is running under a BSD Unix environment using the AFS network
which holds the actual archive files.
All folks at the University of Michigan, as well as out on
the Internet, are encouraged to participate in discussions in
our newsgroup "umich.archives". It's relatively quiet there,
but one post usually can start an avalanche of conversation.
ALL users with access to anonymous FTP facilities are encouraged to use
mac.archive day or night, but we'd prefer if you called during off-peak
hours if at all possible. At this time, there are no restrictions on the
number of simultaneous FTP sessions, so you shouldn't have any problems
getting on. If you have AFS access, you can bypass ftp and help our
ftp machine out by creating a symbolic link to our archives in your
AFS home directory (we're in /afs/umich.edu/group/itd/archive/mac).
For more information about AFS, please consult the file /doYOUhaveAFS
1) What is the mac.bin directory all about?
This directory applies ONLY to users at the University of Michigan.
This is the "natural" version of the archive (all files are unstuffed
and unhexed) that can be "mounted" as an AppleShare volume onto the
Macintosh desktop. Unfortunately, ftp users can't use this directory
at all.
If you'd like to access our mac.bin directory, the solution is to
install AFS client software >AND< "netatalk" software into a Unix machine.
Netatalk is a program that you can install on a Sun 3 or 4, Dec Station or VAX,
and IBM RT or RS6K's. It allows Macintosh computers access to the Unix
directories and file systems. To the end user, it looks and acts like an
AppleShare file server. The source is freely available from
"terminator.rs.itd.umich.edu" in the "/unix/netatalk" directory.
For information, check out the info at "http://www.umich.edu/~rsug/netatalk".
AFS (which is also referred to as Andrew File System) connects universities
and research sites around the world together. The mac.archive files are
kept on an AFS server, and Unix machines running the client software can
"cd" (change directory) into the directory holding the archive files
directly (i.e. bypassing ftp). To the typical user, it's as if mac.archive
was on your local machine.
If you'd like more information on the AFS network and technology and its
advantages, you can send e-mail to "afs-sales@transarc.com" or phone them
up at 1-412-338-4400.
2) What are the .AppleDouble files?
Referring back to the last question, these are the Unix equivalent of
desktop information of a mac.bin file and are appropriate only for use
when using the archive at the U-Michigan. FTP folks should ignore these.
3) What do .cpt, .sea, .sit, and .hqx mean?
These filename extensions are tacked on to help you figure out the
utilities that you will need to get the finished software. All of our
files have been converted from binary to ascii/text format using
BinHex 4.0 format. A MacBinary copy is available in our 00help directory
for you to transfer as binhex4.0.bin. Be SURE to transfer this file with
BINARY or IMAGE mode (or MacBinary mode if using a terminal program or
FTP client that supports it). If you already have a working copy of StuffIt,
Stuffit Expander, or Compact Pro, DO NOT BOTHER downloading BinHex 4.0.
Stuffit and Compact Pro both can encode and decode BinHexed files. Each
of these programs (Stuffit, Compact Pro, Stuffit Expander) does a better
job of it than the original BinHex 4.0.
Files and directories are compressed into smaller, easy to manipulate
"archives" using one of the popular compression utilities. Files that have
the .sit extension have been compressed with Stuffit. .cpt extensions
denote Compact Pro files. Archiving programs and utilities are available
in the "util/compression" directory.
To make things difficult, the extension .sit can refer to any of three
completely different compression schemes: StuffIt 1.5, StuffIt 2.0, and
StuffIt 3.0. StuffIt 1.5.1 (the "Classic" StuffIt) will decode *only* the
first of these formats. If you are having problems, please consult the index
and make sure you are using a program that will decode the compression format
you have.
Another extension you will see is .sea (Self-Extracting Archive). This
type of file is a double-clickable application that will automatically
uncompress itself when launched. The advantage is that you don't need a
utility or decompressor to use it, but it can aid in virus transmission,
so we convert submitted .sea files to their regular archive format (.sit,
for example). We use .sea files only in special circumstances, such as an
actual archiving program or installer. After all, compactpro1.33.cpt.hqx
would not do you much good since you couldn't unmangle the unmangler.
On very rare occasion, you may run across a .pit (PackIt) file. These
archives were pioneers in Macintosh file compression and archiving, but
today they're completely obsolete. StuffIt 1.5.1 and PackIt 3.0 will both
uncompress .pit files, but PackIt is no longer supported, so it's unlikely
that you'll see one. You WON'T find one lurking around on mac.archive.
(StuffIt and Compact Pro are, as are most of the files on mac.archive,
SHAREWARE! Remember to pay your shareware fees to support the development
of these fantastic programs and utilities.)
It goes like this:
If you have a file called
foo.sit.hqx
Then what you do is start from the right side of the name and work your way
left. In other words, you want to get the file "foo". On the right you
see the suffix ".hqx", so you know that you have an ASCII-encoded BinHex
format file. The first thing you need to do is get it into a binary file
for further processing, so you can fire up your favorite archiving program
(StuffIt or Compact Pro) and unbinhex it.
The "textbook" method of handling files tells you to use the BinHex 4.0
application to unbinhex files, but since the archiving apps in use today
include the ability to encode/decode binhex files, BinHex 4.0 is unnecessary,
but you will need it to unbinhex the actual archiving programs! <Catch-22>
There is a MacBinary copy as 00help/binhex4.0.bin. When FTP'd to your local host
in binary mode and transferred to your Macintosh in MacBinary mode, this file
will be ready to use.
For Self-Extracting Archives, all you need to do is double click on the
file, and it will extract itself. So if you have a file named
bar.sea.hqx
You would first unbinhex it, and then double click on the file to extract
it.
4) What about .Z?
As .hqx is the standard suffix for BinHexed files, .Z is the standard suffix
for files encoded with the UNIX program "compress". The only files that we
store in this format are files that require UNIX systems to run. However,
we are aware of some mirrors of our archive that store copies of *all* of our
files in this format. We think this is a really silly thing to do for many
reasons, not the least of which being that it defeats the purpose of the
BinHex encoding. Still, we have little control over our mirror sites: we are
offering our files for free distribution, after all.
To decode a file inding in .Z, you must get it in BINARY mode during your
ftp session. If you transfer it to a UNIX host, the command "uncompress
filename.Z" will usually produce a straight BinHex. If for some reason this
is not possible or doesn't work, the program MacCompress
(/mac/util/compression/maccompress3.2.hqx) will decode this format on your
Macintosh.
5) What about .gz?
This is very similar to .Z, except the files were encoded with the UNIX
program gzip. All of our above comments regarding .Z files hold here, too.
A Macintosh-based gzip extractor is available at mac.archive.umich.edu as
/mac/util/compression/macgzip0.0b.cpt.hqx
6) What does mac.archive.umich.edu do to protect us from viruses?
Unlike other Internet "Mac" archives, we test each and every one of the
files that appears in our "incoming" directory and in our mailboxes addressed
to mac.archive. We use the most-up-to-date virus detection inits and control
panels (Disinfectant, Gatekeeper, etc.) to insure that the files that are
added to the archive are not carrying anything that can harm your Macintosh
and your/our work. We also make these public domain/shareware
virus detection packages available to you as fast as we receive them in
our "util/virus" directory.
HOWEVER (LEGALESE DISCLAIMER) -- WE ASSUME NO LIABILITY OR
RESPONSIBILITY FOR DAMAGE CAUSED BY FILES RETRIEVED FROM THE ARCHIVES
AT MAC.ARCHIVE.UMICH.EDU.
WHERE:
1) Where to find the index and abstract (description) files
Work continues on the index files -- here are the latest versions. The
index files are modified every time new files are added to the archive.
Index info can be found in these files in the 00help directory:
allfiles.txt (446K) a list of all files in the Mac archives
index.txt (1322K) complete list of all files with sizes, compression
schemes, and detailed descriptions for each
index.tab (1171K) a tab-delimited version of index.txt suitable for
importing onto the database of your choice
newfiles.txt (10K) list of files added in the last two weeks
2) Where are closer "mirrors" that I can ftp to?
Mirrors are anonymous ftp sites in other locations around the Internet
that run special scripts to keep up-to-date copies of everything that
can be found in mac.archive.umich.edu. It is sometimes more efficient (and
faster) to ftp to these sites instead of directly to mac.archive.
We are aware of thirty-six (36) official mirrors currently.
== Asia
Hong Kong: ftp.hk.super.net:/mirror/mac
Japan: ftp.ims.ac.jp:/pub/mac/umich
Japan: ftp.crl.go.jp:/pub/mac/umich
Japan: ftp.inter.spin.ad.jp:pub/Mac/Merit.mirror
Japan: ftp.riken.go.jp:/pub/mac/umich
Japan: ftp.eos.hokudai.ac.jp:/pub/mac/umich
Taiwan: nctuccca.edu.tw:/Macintosh/umich-mac
Taiwan: ftp.ccu.edu.tw:/pub/mac
== Australia
Canberra: sunsite.anu.edu.au:/pub/mac/umich
Melbourne: ftp.bf.rmit.edu.au:/pub/mac/umich
Mulgrave: ftp.bhp.com.au:/mac/mirrors/umich
Sydney: gatekeeper.digital.com.au:/pub/mac/umich
== Europe
England: src.doc.ic.ac.uk:computing/systems/mac
France: ftp.loria.fr:/pub/mac/umich
France: ftp.planete.net:/pub/mac/umich
Germany: ftp.uni-paderborn.de:/Mirrors/mac.archive.umich.edu
Germany:
info2.rus.uni-stuttgart.de:/afs/umich.edu/group/itd/archive/mac
Germany: ftp.uni-regensburg.de:/pub/comp/os/macos
Greece: ftp.forthnet.gr:/pub/mac
Italy: ftp.unina.it:/pub/mac/umich
Italy: cis.utovrm.it:/umich
Poland: sunsite.icm.edu.pl:/pub/mac/umich
Sweden: ftp.luth.se:/pub/mac/mirror.umich
Sweden: ftp.sunet.se:/pub/mac/umich (*1)
Switzerland: nic.switch.ch:mirror/umich-mac
Turkey: ftp.bups.bilkent.edu.tr:/pub/umich-mirror
== Middle East
Israel: ftp.technion.ac.il:pub/unsupported/mac/umich
== North America
Arizona: ftp.amug.org:/pub/mirrors/umich
California: mirror.apple.com:/mirrors/mac.archive.umich.edu
California: ftp.cdrom.com:/pub/mac_Umich
Illinois: uiarchive.cso.uiuc.edu:/pub/systems/mac/umich
Missouri: wuarchive.wustl.edu:systems/mac/umich.edu
Oregon: ftp.orst.edu:/pub/mirrors/archive.umich.edu
Quebec: ftp.synapse.net:/mirrors/mac.archive.umich.edu
Utah: ftp.pht.com:/pub/mac/umich
Virginia: mirrors.aol.com:/pub/mac
(*1) - this site in Sweeden also has FSP, Gopher and WWW access
through http://ftp.sunet.se.
If you have lots of extra disk space and some cpu to spare, think about
setting up your machine as a mac.archive.umich.edu mirror. Send a message
to "mike@mac.archive.umich.edu" for exclusive details.
3) Where are WWW Interfaces for mac.archive?
We have a World Wide Web Interface installed at
"http://www-personal.umich.edu/~sdamask/umich-mirrors" and the archive is
also directly available through "http://www.umich.edu/~archive/mac". We will
also have a server at "http://www.archive.umich.edu" but it's not
yet available so stay tuned for more on that.
Other folks have also put together WWW gateways to
the archive. One of the more cool interfaces we've seen is available
at "http://ubu.hahnemann.edu/UBUdex/UBUdex.html". Andrew Brennan
(brennan@hal.hahnemann.edu) created routines and scripts to parse
our massive index into a easily readable format separated by
directory and connected to our archives via Gopher links.
A UK interface was done by Martijn Koster (koster@nexor.co.uk)
at "http://web.nexor.co.uk/mac-archive/mac-archive.html", and a third
is run by Baron Chandler (baron@cristofori.msc.wku.edu) at
"http://www.msc.wku.edu/Dept/Support/Tech/MSC/Macintosh/search_umich.html".
There is also a searchable http interface for the archives
at "http://www.fagg.uni-lj.si/cgi-bin/shase/About/mac-umi".
WHY:
1) Can't users retrieve files from the incoming directory?
Generally, we try to have the files refiled and tested (to see if they
work and screened for viruses) within 2 or so days. FTP users can
see the files in the incoming directory; they can also put new
files into this directory (and they're encouraged to.. see below), but
they can't retrieve anything. Be patient, if you see it there, it'll
probably reappear in it's proper place in 48 hours.
2) Does BinHex 4.0 give me error messages after I have downloaded it
according to the instructions above?
If you are getting the error messages "System Error -39", "System Error -199"
or BinHex 4.0 "cannot be opened because app that created it cannot be found",
then you have NOT downloaded it according to the instructions above, whether
or not you think that you have. Remember: MacBinary transfer in the final
step to get the program to your Macintosh, Binary transfer every other step
along the way.
3) Don't the files unbinhex correctly?
This problem creeps up on us every now and then. The cause can be blamed
on several things (garbled mail, incomplete transfers, bad nullines, etc.),
but since programs like StuffIt and Compact Pro are used by droves of
Mac faithfuls daily, it is safe to assume that these applications are doing
their job properly, so if a file won't unbinhex, it's a good bet that it's
been corrupted. If you run into such a file in our archives, PLEASE drop us
a line at comments@mac.archive.umich.edu and we'll take care of it, and drop
you a line when the problem is solved. However, don't mail us without
trying to de-binhex a file with either StuffIt or Compact Pro. There
are several programs, including at least one auto-de-binhexer, that choke
on legitimately binhexed files. Ironically, there are many files that even
BinHex 4.0 can't de-binhex. Neither Compact Pro nor StuffIt have this
problem. When you download BinHex 4.0, you should immediately download either
StuffIt or Compact Pro, decode it, and trash BinHex 4.0 (Really...).
If you cannot download files directly to a Macintosh but you instead must
transfer them through another computer (such as an IBM compatible, for
example), you're stuck. You need to bootstrap yourself, and there is *no*
simple way to do this. Once you get a working copy of BinHex 4.0 (or Compact
Pro, or StuffIt) installed on your Mac, you're all set, but there are *only*
two ways to do this: download it directly to your Mac or get a copy on
disk from a friend. It is impossible to get a working copy of BinHex 4.0
(or Compact Pro, or StuffIt, or any related program) from an IBM compatible
without having one of those programs present on your Mac FIRST.
Also, remember that BinHex files are pure TEXT, so they must be transferred
in ASCII or TEXT mode at all times. Transfers in BINARY or IMAGE mode will
more often than not just corrupt the file.
4) Can't I get into the umichlicensed directory?
In this special directory we keep University of Michigan site licensed
software, such as MacX or Maple. This is software available only to
U-M affiliated people and as such, we can't allow anonymous access to
these files.
If you are a U-M student or staff member and have a "umich.edu"
uniqname (e.g. my uniqname is "myke"), you shouldn't use the
mac.archive.umich.edu anonymous ftp sites for your file transfers, but
instead use machines that allow authentication, such as the ITD Unix
Login service (e.g. "login.itd.umich.edu"). You can ftp there with
your uniqname and kerberos password, cd into
"/afs/umich.edu/group/itd/archive/mac" and retrieve files from all
the mac.archive directories, including the umichlicensed directory.
This same philosophy applies to the mac.bin directory, you need to
have "/afs/umich.edu/group/itd/archive/mac.bin" added to your
AppleVolumes file. You can then authenticate to the IFS/AFS servers and
access the materials in the UmichLicensed folder.
5) Can't I Gopher files from UM's GopherBLUE?
Users who attempt to transfer files through UM's GopherBLUE service
will get a "can't transfer in secure mode" error. The reason
for this is that the server doesn't know what kind of machine and
method to use to get the files to you. Obtain an UNIX account
and use that machine's Gopher client to hook up to
"gopher.archive.umich.edu" and transfers should go smoothly.
HOW:
1) Can users upload files?
Of course! Please do! The best (fastest) way to get files to our archive
is to ftp-put them into the incoming directory, then e-mail
"questions@mac.archive.umich.edu" and let us know that you've submitted a
file. This way we'll know there's things to be done, and also know who to
contact if the files don't work "as advertised."
You can also e-mail files to mac.archive (and many other international
mac archive sites) by sending your binhexed/compressed files to
"macgifts@mac.archive.umich.edu". There is no need to send a confirming
message to "questions", nor will you receive a confirmation back
(it's just a mail-exploding alias). It's a good idea to put some type
of explanatory blurb, or introduction, before the BinHex file in the
message you send to "macgifts".
A more detailed description of our submissions policies can be found as
/mac/00help/submissions.txt
2) Can users retrieve files by mail?
We have our own mail-server named BART. Send BART a message at
mac@mac.archive.umich.edu with any subject and the single word 'help'
(no quotes) in the body of the message for complete instructions.
3) Can users access the archives without using ftp?
Certainly! In addition to BART and afs access, we have a gopher server at
gopher.archive.umich.edu. You will need MacTCP and /mac/util/comm/turbogopher.
The above mentioned mirrors are usually current within a day, too.
4) Can users get on the groovy recent-files & news mailing list?
This is the very same list of new files and information that is
mailed out, somewhat irregularly (around every two weeks or so), to
the "comp.sys.mac.digest" Usenet group. To get on the mailing list,
send a message to the address "mac-recent-request@mac.archive.umich.edu".
It'll be a human answering this address, so don't send blank messages
or single word "help" notes. We like knowing exactly what you want
us to do.
Once again, thanks for taking the time to read this introduction note.
We're working hard to make this one of the most popular archives
available on the Internet. Let us know if you have any questions,
comments or ideas. We value your support, and appreciate your feedback.
Have a groovy time on mac.archive!