This new version is greatly improved over the previous ones, so if you know suntar 1.0 you could wish to read the documentation to discover new features. The basic philosophy is unchanged, but the program was largely rewritten. The number of changes is so big that we list only the most important ones:
Ñ the user interface has changed, now you may scroll to see messages which are no more on screen and set the font, size and style of the displayed text. And suntar 1.1 is less modal, that is it lets you do things in the order you wish rather than in its preferred sequence, hence it's easier to use
Ñ it's more unexperienced user-proof (and idiot-proof, if you want that): it warns you about silly actions such as trying to write on an 800 Kbytes disk which can't be used to transfer data to a UNIX machine
Ñ suntar 1.1 is MultiFinder aware and System 7.0 compatible (and partially System 7 savvy: it supports aliases and balloon help)
Ñ it recognizes and decodes .hqx files
Ñ two different multivolume formats are supported in both reading and writing.
In short, it looks and behaves more professionally, but its price is not more professional: suntar 1.1 is still freeware.
What's suntar ?
Suntar is the cheapest way to transfer data between a Macintosh and an UNIX workstation, if a few hardware requirements are met.
To understand what it does, it's useful to tell how the whole thing started: we had just got the new, wonderful Macintosh LC, but one of us is a student and at the University he had to work on a Sun SPARCstation 1: is it possible to communicate data between the two machines, without using a network or a modem ? The SPARCstation has a 3.5" disk drive, why shouldn't it be possible to save a file on a floppy disk at the University and read it back on our Mac, or vice-versa ? That would be useful both for working (typing a C program at home before compiling it on the Sun) and downloading Mac files from all those ftp-able places in the world.
The Apple SuperDrive can read and write disks in the two IBM formats, 720K and 1440K with MFM encoding: for simplicity and compatibility, all 3.5" drives manufacturers have adopted this de-facto standard, hence there should be no difficulty to read a disk written on any UNIX workstation on a Macintosh with a SuperDrive. Unfortunately, for a while Apple did not adhere to that standard, the 400K and 800K drives used exclusively an Apple proprietary physical encoding called CGR which can't be read or written on a non-Apple disk drive.
But the SuperDrive is compatible, and it's present on all most recent Mac models: that is the IIx, IIcx and later models of the series II, the SEs built after September 89 or upgraded with a FDHD kit, the SE/30, Portable, Classic and LC: today, all Macintosh models in production have a SuperDrive.
Furthermore, the ancient UNIX hasn't learned yet about floppy disk drives: they must be set up to emulate a tape drive unit, handled by the tar utility. That's good for us, since tar uses a simple, standard format: no allocation tables, inodes and other complex, nonportable data structures, files are stored sequentially preceded by a simple header containing their name and a few informations; for directories, there is only the header, contained files are stored separately, using the partial path name from the directory you specified.
So, we wrote suntar, a program which runs on a Macintosh and reads and write a disk in the physical IBM formats containing data in the logical tar format; thinking that it could be useful to many students having the same problem, we added more features, made it easier to use and released it in the public domain.
Really, there are three different floppy disk formats you may use on an UNIX workstation in order to exchange data with a Mac:
1) the Macintosh format: we' ve read on a magazine about two commercial programs which, running on UNIX workstations, should read and write disks in Macintosh format. We have no information about the price, features and reliability of such programs, hence we can't judge its fitness to your needs
2) the MS-DOS format: the public domain package "mtools" can read and write in the MS-DOS format under UNIX, and Apple File Exchange can then move the data to your Mac. Inconveniences of such approach are: to move files bigger than a disk is possible but annoying (you must split them); you have no support for Macintosh specific file formats, hence you must own a bunch of file format conversion utilities and use them properly (for example, AFE can translate a MS-DOS ASCII text to a Mac ASCII text, but you must disable such conversion on UNIX files, and convert later); lastly, the portability of UNIX programs is a myth, you get a public domain package in source code but you need the help of an experienced programmer to have it compiled and running.
3) the UNIX formats, that is tar and bar formats. Suntar can read and write such archives, and performs all the most useful file conversions while doing it.
Under UNIX, tar may be used for three purposes:
1) to perform regular back-ups on tape, to be stored and hopefully never used; or to archive rarely used files off-line, on a medium which is cheaper and more capable than a hard disk: that's where the name tar (Tape ARchiver) originally came from.
2) to put together several files into a single file, which may be easier to manage, expecially if you wish to compact it (both the old pack utility and the new compress generate one compressed file per input file).
3) it's the simplest way, and sometimes the only way, to create a physical medium which can be used to distribute programs and data to other computer users.
Suntar was conceived to be mainly a communication program, role 3, allowing Macintosh users to exchange data with UNIX users. It can be used for backups, role 1, but there are many backup programs specific for the Mac which are much better. If you happen to have a .tar file on a Macintosh you may extract it by suntar, but to perform role 2 in the other direction is a little tricky, you should rather use a compression program such as StuffIt or Compact Pro or, if tar format is required, use Craig Ruff's tar: it's a public domain Macintosh program, the 3.0 version was released just two months ago and has added the capability to read/write from an UNIX floppy disk, but in that role it's less powerful than the older suntar 1.0: that is, the roles of tar 3.0 and suntar 1.1 are now slightly overlapped, but since both programs are free you may get both.
Instructions, UNIX side
You may use disks formatted on the UNIX workstation, on an IBM PS/2 or on the Mac, either under suntar itself or Apple File Exchange or the Finder (1440K only); in disks formatted for the Mac there must be something different, since the Mac recognizes them as Mac disks even after they are full of data in tar format, but the SPARCstation does not complain. Anyway if you have problems, try not to use disks initialized on the Mac, or initialize them under Apple File Exchange.
Beware: MS-DOS and System 7 have a feature that allows you to use disks having bad sectors, by marking them in the allocation table. A tar disk has no allocation table, any bad sector will be used for data if the archive is long enough to reach that sector. Hence, if you have doubts about the quality of your disks you should initialize them under System 6 or suntar, where initialization fails if there are any bad sectors.
On the SPARCstation, the typical operations are performed as follows.
Formatting:
fdformat
(fdformat requires no parameters and prints the correct device name you'll need for the following commands)
Write one or more files or directories:
tar cvf /dev/rfd0 filenames
(use the proper name in place of rfd0, the floppy drive device, and write the list of files and directories in place of "filenames" )
Append:
tar rvf /dev/rfd0 filenames
List:
tar tvf /dev/rfd0
Read:
tar xvf /dev/rfd0
Refer to the manual of your system for differences and for other options, or type "man -k disk" for the online help, if it's installed.
The original tar utility can't create an archive longer than a single disk, maybe that was a reasonable limit on tapes but it's not on floppy disks, we happened to download more than 10 MegaBytes of public domain files at a time and to manually distribute files among the disks, without exceeding the 1440K limit on each, is really tedious. There are two ways to overcome that: one is the bar program, which might be part of the set of utilities which came with your UNIX (on the SPARCstation it's so). Bar generates archives in a format similar to the tar format, but allows an archive to span any number of disks. To run bar, simply replace tar by bar in previous examples, and it will eject disks when they are full and will wait for you to insert a new one. Really, bar was badly designed (if a data field happens to be written in a wrong way one should correct the problem, not let the extraction routine ignore that field), and the documentation of its format is full of errors, but according to our experience suntar succeeds to read bar archives without problems.
Then there is the GNU tar. GNU is an association which freely distributes a set of UNIX utilities compatible with the original ones, in source code: you may get them by anonymous ftp at prep.ai.mit.edu. The GNU version of tar has a few extra options, by specifying M it allows multi-volume archives (that is, type cvfM, rvfM, tvfM, xvfM as parameters); an extra parameter V may be used to assign a sequence number to disks. GNU tar does not eject disks, hence if the drive hasn't an eject button you must keep open a second shell window to issue the eject command. If your tar does not happen to be already a GNU tar, remember to get the help of an experienced programmer, the source code was written to be portable among several machines (even MS-DOS) but you must taylor some #define's to your system and maybe find where some .h files are; and if your C compiler follows the ANSI standard, disable all the new features: portability of source code for UNIX systems is not perfect, it's difficult to do better than that.
Instructions: Macintosh side
If you are using System 7, turn on balloon help to get short descriptions of the commands; otherwise, read here.
The first command in the File menu is the usual Open, but you'll rarely use it: it opens a Macintosh file on a Macintosh volume containing data in the tar or bar format, useful only if you have another mean to communicate data or if you happened to download a .tar.Z file and you expanded it on the Mac. Copy archive to tar file creates a file in this same format, by copying all data found on a disk (for multi-volume archives, the extra volume headers on disks other than the first one are skipped, so you get a single-volume archive).
The usual way to begin to work is by inserting a disk: suntar realizes that the Finder didn't recognize it and "opens" it for itself. Otherwise, you may select a command and suntar will ask you to insert a disk, opening it as a tar/bar archive even if the Finder did recognize it. The Eject command may be used when you no more need the disk, but most commands eject the disk when finished. Anyway, it's not a good idea to keep a non-Mac disk in a drive for a long time, expecially under MultiFinder. The usual command-shift-1 and command-shift-2 still eject the disk, but suntar doesn't realize that the disk is no more there: use Eject or its shorcut command-J instead (yes, that means that you can't run suntar from a floppy disk if you have a single drive).
List prints the list of the files in the archive: the 1.0 version had two List commands, for tar and bar formats, suntar 1.1 recognizes the format and needs only one command for List, Extract and Append.
Extract reads files and saves them on the Macintosh. However, the Macintosh files are different from UNIX files: they are composed of two parts (the data and resource forks) and their attributes are essential (you can't execute an application if its type is not 'APPL', nor extract a StuffIt archive if it's not 'SIT!'); even pure text files are different, since UNIX separates lines by a LF character and the Mac by a CR (MS-DOS uses a CR followed by a LF, just to be incompatible with both). To make things easy, suntar recognizes the most common file formats and automatically converts them to the Macintosh form. That includes pure text files and the two formats used by public domain archives, MacBinary (in three variants) and BinHex (.hqx files); in most cases, you get exactly what you want without having to worry about which conversions must be done.
The two Create commands allow you to start a new archive, overwriting anything was previously on the disk (in Mac style, you may get a few warnings before loosing any data; to delay data loss, suntar writes any volume header only after you choose the first file to be written). Append is similar but preserves the current contents of the tar/bar archive, adding new files after the existing ones. Anyhow, when you are in write mode you select commands in the Write menu and the familiar standard file dialog appears: the Write button allows you to select whole folders, it's equivalent to Open for single files. Choose End of write (or Eject or Abort or Quit) when you have finished.
Files can be written in three different formats: MacBinary saves all the data of a Mac file (using the MacBinary II format, which can be read also by programs which know only about the original MacBinary), ASCII saves the data fork only converting any CR to LF, Data fork only must be used for files already in UNIX format. Lastly, write tar file does the reverse of Copy archive to tar file, appending the contents of the tar file to the archive, without doing any conversion.
Initialize is like the Initialize command in the Finder, but disks which do not support 1440 Kbytes (have no hole...) are formatted at 720K, a format more suitable to exchange data with UNIX machines; they are initialized in a way that is completely Finder compatible, but their main use will be as non-Mac disks.
Pause and Abort are what you expect, but you'll be surprised to find them in a menu, in most programs they are missing or are buttons. Well, suntar allows you to pull down menus even when it's working, even when it's performing very low level operations, directly talking to device drivers. That can be very useful, and working in background under MultiFinder saves time, but it may be dangerous: as any UNIX application, suntar knows only a drive number, not a disk name: if you eject the tar disk from outside suntar (or you use command shift-1, or the Finder ejects it with its usual change disk dialog or the Eject button in the standard file dialog) and insert a Macintosh disk, suntar will not notice the difference, and if you do that while suntar was writing and the second disk contains the only copy of your most precious data... To avoid that, you may pause suntar, eject the disk and then insert it back: if suntar is in foreground it will ask you whether that's the same disk it was working on. At any time you may change the preferences settings, to become active at next file (the best moment to do that is during the confirm saves dialog) .
Similarly, you may select any enabled command during semimodal dialogs: they look like modal dialogs, except for the window border, but behave differently: you may do anything while they are out, including switching to another task, moving the dialog and (by holding down the command key, as usual for non-front windows) moving the console window, but you can't hide one of them behind the console.
In the Preferences menu, English selects the language of messages (Italian or English, the default depends on the national version of your System file).
Confirm saves allows you to extract only some files from an archive: it is a three-state item, clicking on the buttons "Skip all" or "Save all" puts it in a temporary state, you may return to the normal state by choosing it again.
The .hqx prefs submenu is useful if you often download BinHex files. The problem with such files is that they are plain text files. That's good since they may be sent as E-mail and transferred also in the default mode of ftp, without switching to binary mode, but it's bad since they can be, and usually are, edited before arriving at you. So, they may contain extra text or be incomplete: you may disable conversions if suntar fails to extract them and you wish to try again with a specific program. Usually, before the BinHex data there is some text: sometimes it's the only user manual for the application or INIT in the file (and an INIT has no about box and no menus...), other times it's totally useless; so you may want to save that text in a file, or see it on the console, or simply skip it.
Suntar uses some statistics of the data to recognize ASCII files, but statistics requires many data, so for very small files it can't always guess correctly: if the option "Small files are ASCII" is enabled, suntar tries to convert all files, otherwise files shorter than 80 character are always saved as non-ASCII data.
Select Expert mode and suntar will show some new preferences and a new menu which you will rarely use: Find headers is essentially a "find all files, including lost and deleted ones", Read tar at sector recovers them, Do it again repeats the last command if it was a View, Read at sector or Expert list. Anyway, since MacTools, the Norton Utilities and other disk utilities will not recognize a tar disk, it's reassuring to know that suntar has some undelete capabilities for disks which crashed or were partly overwritten. We happen to use Read tar at sector as an alternative to using Extract in "Confirm saves" mode, since it can extract a single file in any part of a crowded disk: its non-Mac user interface may be less annoying than to wait for a lot of files to be skipped and reselect the Confirm saves on the fly just before the wished file comes out. Maybe a future version will allow to select files from a scrollable list, but by now those two techniques should suffice.
What you need
To exchange data is a difficult art: if you want to fully exploit suntar you should have some basic notions about Mac files: data and resource forks, the MacBinary format (a common way to store a Mac file in an UNIX-style file without losing informations) and so on.
If your purpose is to download files from ftp-able public domain archives, you should have a bunch of other public domain programs to convert file formats:
Ñ .bin files (and all non-ASCII formats) are MacBinary files, directly converted by suntar; you should not need any of the many small utilities performing such conversion, such as BinHex 5.0 (which is a totally different program from BinHex 4.0)
Ñ .hqx files may be converted (usually yielding a .sit or .pit) by suntar itself, by BinHex 4.0 or StuffIt or Compact Pro or many small utilities; usually these programs can't decode files splitted in several parts: if you get a set of parts, use United or Unity (or any text editor which accepts very large files) to put all parts together (without any extra text: an '----- end of part 1' often makes the extraction fail)
Ñ .pit files were created by PackIt, but StuffIt too supports them by an unpack command
Ñ .sit files are almost a standard, recognized by several compress programs on the Mac: their originator (StuffIt 1.5.1) or Compactor and Disk Doubler. However, StuffIt has now evolved to a commercial version, StuffIt Deluxe, with a new, incompatible format. Deluxe archives may be extracted by Stuffit Classic 1.6 (shareware) or UnStuffIt Deluxe (freeware)
Ñ .cpt files were generated by Compactor (recently renamed Compact Pro); the extract-only version (Extractor) is freeware
Ñ .sea files were created by Compactor too, but they self-extract themselves when you double click them.
If you exchange UNIX files instead of Mac files, you'll need MacCompress which is compatible with the UNIX utility compress (.Z files).
Usually, suntar automatically converts LF to CR when reading, and using "write ASCII" it converts CR to LF when writing. If a file contains non-ASCII characters (codes bigger than 128, such as Ñ or ⌐) they are copied unchanged, but probably the other machine will not recognize them; you may need some file-conversion applications to solve such problems (we use Xform).
Finally, DeskZap 1.32 is always handy to change file type and creator, set the bundle bit (some programs come with an icon which is not shown by the Finder because the author has forgotten to set the bundle bit) and perform simple file format conversions, and the desk accessory System Errors may tell you the meaning of error codes which suntar prints when something is wrong.
Personalizing your copy of suntar
If you have ResEdit you may permanently change some settings of suntar. As in almost any Mac application you may add or remove command-key equivalences of menu commands. Then, you may set or remove the check mark in the Small files are ASCII and Expert mode menu items, or in any item of the .hqx preferences submenu, but no other item. And you may alter the size menu, provided that the first item remains '9'.
All the 'STR ' resources are permanent options, their title explains their meaning. You may choose a different creator for plain text files (EDIT for the Consulair Edit or its "compatible" Edit II, ttxt for TeachText, MACA for MacWrite, MSWD for MS Word...); or you may tell suntar not to issue some warnings (writing an 800K disk which can't be read on UNIX) or questions (create a GNU tar multivolume archive ?). Ok, using ResEdit is not the best way, an options box is on top of our "to do list" for next release.
Suntar and System 7.0
Suntar 1.1 is coming in the days of System 7.0, hence we were obliged to cope some new problems. Previous versions followed Apple rules, hence were already System 7 compatible, meaning that they did run under it, but without exploiting it. This new version goes a little further: being MultiFinder aware, it's better integrated in the new environment, but that is still a System 6 feature. And we checked that it is 32 bit clean and set the relative bit to say to the Finder there is no danger to run it in virtual memory.
By now, suntar has three System 7-specific features:
Ñ it can save whole volumes, it suffices to select a volume in the standard file dialog
Ñ it recognizes aliases. All pre-System 7 back-uppers and archivers can resolve aliases when you choose them directly by the standard file dialog, but if you select a folder and it contains an alias, what goes into the archive is a 500 to 700 bytes file which says to the Finder where the true file or folder is. Obviously, it's useless to upload such informations to an UNIX machine, hence suntar 1.1 resolves any aliases it finds (obviously that means that you will find two copies of the same file when saving a folder containing one copy plus, maybe in a subfolder, an alias).
Ñ it provides ballon help for almost all menu commands
Copyright notice
Suntar (Speranza's un-tar) is freeware, so you may freely distribute it and send it to other public domain archives. If you send it to an archive which is more easily accessible from UNIX machines than from the Mac, you should send it in both forms, the StuffIt archive for who can download it and the uuencoded file (which includes instructions to use it) for those who need to "bootstrap" their communication link between UNIX and the Mac, by creating a Mac disk containing suntar using only UNIX utilities and a 3.5" disk drive connected to an UNIX machine.
All the routines for creating and extracting files in tar format, plus the MacBinary conversions are from the programs muntar 1.0 and mtar 1.0 ⌐ Gail Zacharias 1988, whose source code is available in public domain. We did a lot of little improvements (for example, muntar recognized only the main variant of MacBinary), added support for GNU tar and bar archives, and transformed them from file format converters with a pure UNIX-like interface (under the MPW shell) to a communication program with a Mac-like interface.
We have examined programs by Dave Johnson and Peter Lewis for the BinHex decoding, but the final routines were written anew.
Suntar was written in Think-C 4.0; the 1.0 version used the ANSI standard library, ⌐ Symantec Corporation 1989, but the new 1.1 version has a user interface library of its own, built from demo programs by Symantec (MiniEdit.c) and Apple Computer (TESample.c), and a lot of original additions: semimodal dialogs, the SilentSuppression which deletes old text when the console approaches the 32Kbytes limit of TextEdit, the autoSelect and autoCopy features (in view sector, try to select some read-only text and then type command-V) and the possibility to dynamically enter and exit the autowrap mode; suntar is also potentially multiwindow, but we did not find any use for further text windows, so you may see only one.
We have sent the source code of suntar 1.01 to all those who asked it, but maybe it was not very comprehensible with all comments in Italian. We haven't decided yet what to do with suntar 1.1, maybe we'll make available the source of the tar portions (translating the important comments to English) and only the object code for the user interface library. Anyway, the whole source will be made available when we'll lose access to the Internet and we'll be unable to further support it, what will happen when Sauro will graduate and leave the University, sometime in next year.
Suntar 1.1 is much more complex than suntar 1.01, but it was not tested any longer: hence, expect it to have more bugs than the previous version. You may help us to make it better by sending your bug reports (including grammar errors in the messages and inconsistent behaviour), suggestions and questions to:
mail address:
Sauro & Gabriele Speranza
via Cappuccini 18
40026 Imola
Italy
(yes, it's the town where a Formula 1 grand Prix takes place)
E-mail in INTERNET (as long as I study at the University)
Sauro Speranza
speranza@cs.unibo.it
or: speranza@leporello.dm.unibo.it
Letters from previous users have reported successful use of suntar in exchanging data with the following machines:
Sun SPARCstation 1
Sun SPARCstation IPC
Sun SPARCstation 2
IBM RISC/6000
users of other machines had problems, but the problems arised before succeeding to move suntar to a Macintosh, hence by now the list of incompatible machines is empty.
On the Macintosh side, having a Superdrive is the only requirement, and an external unit should be good; maybe suntar could even recognize and use a 5.25" disk drive connected to the Mac; surely it will not use a tape unit. Maybe those third-party 1440K drives connected through SCSI are not good, we don't know: that means that suntar is scarcely useful if you have a Mac Plus, it should run but without a SuperDrive you can't exchange data with an UNIX machine.
If you have any problems, or if your machine is not in this list (for example, you use a NeXTstation, an Apollo, HP, or a 386 PC used under UNIX) and the time passed from the writing of this documentation is not great in comparison with the diffusion of your system, please let us know so we will be able to update this list of compatible hardware.
