Abstract: Since we also use some legacy systems among our machines, this page contains useful configuration and usage hints for Mac OS X as well as Mac OS Classic systems. Hints have been selected for things that are less obvious, yet are needed for smooth operation, and for informations that may no longer be so easily available for someone running only most recent machines.
.ics
and iCalendar refuses to recognize it with this error message:
This server offers basically only afp (Apple Filing Protocol) services with restricted access (via Login/password). This server is protected by several firewalls and resides in the zone ETHZ-VPZ_UWIS. It may also offer some additional services such as ssh and ftp etc. However, such services are not for general use and are reserved for administrators and developers only and are only possible from certain machines.
For access hints click here
Note that the entire se-server is protected from data loss by a daily netbackup
For access hints click here
Note that this service is protected from data loss by a daily netbackup
Note that all simulation servers are NOT protected from data loss by any backup. It is your responsibility to avoid data loss, since you should use those simulation servers only to run some simulation experiments, analyze and archive the results, and, once finished, delete all files you used. The only exception to this is the huron, which receives a daily netbackup.
AFP stands for Apple Filesharing Protocol. You can also construct URL's of
the form afp://se-server.ethz.ch/SE_Intenr...
to specify a
particular folder or file on an AFP server.
To access one of the offered afp services use Finder's menu command "Go -> Connect To Server" (Command-K) or the "Chooser" (MacOS Classic) and enter the "Server IP Address" of the server, e.g. se-server.ethz.ch similar to this:
Mac OS X
Mac OS Classic
Then login with a dialog similar to this:
Mac OS X
Mac OS Classic
and choose one or several volume(s) to mount
Mac OS X
Mac OS Classic
and click OK.
It is not recommended to check any volumes to the right of the list, i.e. please refrain from auto mounting shared volumes. Thanks!
FileMaker services are only available using the FileMaker application. It is recommended you do this only from within your personal literature data base LiteratureMY. To succeed you need a working TCP/IP based connection to the Internet.
Finely edited help, hints, tutorials etc. can be found at OSX FAQ.
Here you may find an answer to some of the more pertinent questions you might have with respect to MacOS X.
To maintain a consistent, well synchronized time stamp among different machines use the Control Panel Network Time (or the built in facility on OS 8.5 and newer) to set the time. The settings are these:
Under MacOS 8.1 don't touch the time zone settings. Leave this entirely to the control panel "Network Time".
Recommended date format:
Recommended time format:
Above settings ensure proper back up, file transferal when updating between development servers and your local machine, working of M2 mode in Alpha or macros in MEdit, working and sorting of our literature data base. Please stick to them!
You will often need ftp to transfer files among hosts. ftp is particularly useful to transfer large files, which otherwise risk to get intercepted if sent by E-mail attachment. For ftp you should configure your ftp client, e.g. Fetch, in such a way, that you encounter a minimum of problems. This is particularly important for Systems Ecology modelers and developers, since the Development server (SED - Systems Ecology Development server) holds thousands of masters for many kind of files we need in our daily work. The integrity of these files can only be warranted if you follow a few precautions as explained below.
Rules of thumb if in doubt:If possible avoid text mode, it may corrupt data! To a Mac upload all files in binary mode! To a Sun upload all files in raw data mode! To an IBM PC upload all files in raw data mode! |
If you use Fetch on a Mac to download and upload files, e.g. from/to SED, you should configure Fetch as follows:
This ensures that in automatic mode you will upload any non-text file, e.g. a SBM-file or an application, as a 1:1 copy from your Mac to the SED. Text files will also be uploaded correctly, given for reasons explained below. Moreover, note the option "add no .bin suffix" will quietly overwrite any already existing file with the same name. This is usually what you want. This also avoids getting a mess on the SED.
Be careful, however, with this overwrite option. In particular make sure, before you edit a file, which already exists on the SED, that you have currently the master rights and that you edit starting from the most recent version. |
There is a subtle advantage to this method for Alpha users. Alpha's ftp filesets or the ftp menu offer a convenient remote editing of files. If you use Fetch as the helper application to accomplish the involved ftp, these settings allow you to access files on a Mac as well as on a Unix machine. Since you do only upload the data fork in above settings, any remote editing of text files via Alpha is well supported.
Finally note, above settings work generally well, since the SED is configured in a way, which allows to upload text files conveniently and safely from any platform. In this mode you upload text files as if you would NOT do it from a Mac (see next hints), i.e. only the data fork is transferred. Extensions are then used to actually assign the file to a particular application (see below). Note, this may imply, that the transfer gives the file to another application, e.g. uploading an Alpha file with extension '.PRJ' will result in a file, which is owned by RAMSES (see table below). However, a file with no extension uploaded in text mode, will be owned by SimpleText (see table below). This is usually no big problem, since what matters most for the release machinery based on the SED server, is that text files are stored as files of type 'TEXT'. Otherwise the release machinery fails. E.g. any MPW script not of type 'TEXT' crashes. Any file to be distributed in a release and which is not of type 'TEXT' will end up in the release as a binary file of an unknown application!
Should you exceptionally wish to upload a text file from a Mac including its resource fork, e.g. because you wish the file to be owned by a particular application, e.g. Alpha or MPW, then you best upload it in MacBinary II mode. E.g. use button "Put File..." or temporarily change your preferences. Then you will get a 1:1 copy of the file even in text mode.
If you use Fetch on a Mac to download and upload files from/to SED, you should configure Fetch similar as described above, but with some differences. These are the recommended settings:
OS X does not see the resource fork of files. Since ftp normally works only with the data fork, the resource fork is lost unless you take certain measures (see below). For many files, e.g. source code files, the resource fork is irrelevant. It may contain information on last selection, fonts, or tab width, information which is rarely essential. However, for other files, e.g. applications, the resource fork is essential and must not be lost. If you download such a file from our X Server, then you will obtain a corrupted file.
Uploading of such files should be done with format "MacBinary III". On a X Server the option "Add .bin suffix to MacBinary III uploads" ensures that the file is characterized as a MacBinary file. A MacBinary file contains the resource fork stored within the data fork. Thus both forks are transferred during a ftp transfer. When you download such a file, Fetch will unpack it and the result is an identical copy of what you have originally uploaded.
However, if you mount the X server via afp, a MacBinary file does not behave normally, since it has an empty resource fork. If you wish to use it directly, and without downloading it first via ftp, you can unpack it by drag-and-drop onto utility "StuffIt Expander". Then the file is restored to what it was before the upload. Note, however, once unpacked a download via ftp is no longer possible. You need AppleShare access to download it.
It is recommended to use afp to download such a file.
If you have no access to afp and would like to use ftp, then
you would need first to issue a packing command to the remote X
server, asking to convert the wanted file into the MacBinary format.
The subsequent download would then result in the wanted file. There
is a tool called macbin
which can accomplish this task.
You need to login by ssh (available to programmers of Systems
Ecology), using e.g. application Terminal, go to the directory where
the wanted file sits and then encode the wanted file:
cd <path to directory where myfile resides> macbin -e <myfile> > <myfile>.binThe result is then a file with the same name as your original file, but encoded (-e) and with extension .bin added. The encoded file can be downloaded via ftp. Using Fetch will result in the reconstruction of the file exactly as it was present on the X Server.
Ex.: Lets assume you have a file called MyFile.app in directory Anschlagbrett on our server volume SE_Intern. The commands are then:
cd SE_Intern/Anschlagbrett/ macbin -e MyFile.app > MyFile.app.binThere is one drawback with using
macbin
: It does only
encode for MacBinary II format, not the more uptodate MacBinary
III format. Note, all ftp users login to /Shared Items/FTPRoot/
.
What you see are actually only symbolic links to all available share points.
Non-text files should be transferred in binary mode between your machine and the SED. This does not affect the content in any way and 1:1 copies should result. However, permissions, e.g. for executables, get lost and must be set again.
The situation is more complex for text files, since most ftp clients affect the content of text files. Uploading of files via ftp from Unix and IBM PC machines is no longer a problem, given the ftp client does not affect the content of the transferred files. Thanks to the current configuration on the SED, each file is automatically assigned to a particular application. Of course, only if there exists one on the Mac, i.e. Unix or IBM executables remain what they are (given they were transferred in binary mode!). Using the "Internet Config" extension, this technique interpretes the extension of a file and assigns a creator (signature) and file type according to the extension of the file. All standards are supported plus the following special extensions, which are of relevance to us:
Extension | Application | Creator (signature) | File type | Comment |
.MOD or .mod | Alpha | ALFA | TEXT | Modula-2 program or implementation module |
.DEF or .def | Alpha | ALFA | TEXT | Modula-2 definition module |
.PRJ | RAMSES Shell | RAMS | TEXT | RAMSES project file |
.DAT | Alpha | ALFA | TEXT | Any data file |
.DTF | Alpha | ALFA | TEXT | Any data frame file |
.txt | SimpleText | ttxt | TEXT | Any editable, simple text file |
none or unknown to "Internet Config" | - | hDmp | BINA | file transfer mode is binary |
none or unknown to "Internet Config" | - | SimpleText | TEXT | file transfer mode is text |
Using Unix hosts, ftp preserves the essential content of text files when
transferring in text mode. In particular note, that uploading a Modula-2
file like a .mod-file from a Unix machine to the SED, results exactly
in what we need: The file becomes a text file, which is owned by Alpha,
and EOLs are translated to the Mac EOLs (CR). Fortunately, the content of
the file is otherwise not affected, and special characters (>126) are fully
preserved during down- and uploads. Consequently, if your Mac source
should make use of special characters, such as 'ö'
in a string, this
character will be preserved during a down- and upload between a
Unix host and the SED. Only if you really wish to translate such
special characters, you have to do it explicitely on the Unix or IBM PC.
Then you have to make sure to translate correctly in both ways, i.e. before
uploads or after downloads. Neither the SED nor ftp will do it for
you!
Should your ftp client affect the content of a text
file, it should only translate the EOL (end of line)
accordingly to the target machine. However, it is
NOT recommended to make use of such a feature.
Note, on the SED it is currently
Apple's standard ftp server, which performs the ftp
service.
Using a raw data mode instead of text mode, could be
preferable when uploading files, since this does not
change the content of a text file in any way. Should
your ftp client insist on translating the content of
text files, force it to translate for a Mac.
A solution might be to avoid any translations at all, i.e. also excluding the translation of EOLs. This means avoiding the text mode at all. For example, from a Unix host upload in binary mode. The resulting file will be a 1:1 copy. In particular, EOL remains that of UNIX (LF) or IBM PC (CR,LF), yet the file type is 'TEXT' and it is owned by Alpha, e.g. when the extension is .mod etc. Most importantly this means also, you have to fear no disturbance of the RAMSES releasing machinery. Moreover, if you use a Mac, Alpha can still correctly open and edit such a file. The only disadvantage is, if you wish to make file content comparisons with Alpha, you will have first to make the EOL conversion on the Mac. Then, the drag-and-drop utility "ctc 1.5" comes very handy. It can translate the EOLs in any way for any number of files. This utility is contained in the RAMSES Extras release. |
Rules of thumb if in doubt:If possible avoid text mode, it may corrupt data! To a Mac upload all files in binary mode! To a Sun upload all files in raw data mode! To an IBM PC upload all files in raw data mode! |
Some useful hints can be found here.
We have an entire web page dedicated to trouble shooting.
Back to:
Top of page
Terrestrial Systems Ecology
Environmental Physics (UP)
Institute of Biogeochemistry and Pollutant Dynamics (IBP)
Partner institutes:
Institute for Atmospheric and Climate Science (IAC)
Institute of Integrative Biology (IBZ)
Department of Environmental Systems Science
ETH Zurich
Responsible for content: Andreas Fischlin ( Last modified 10/29/24 )