Accessing Unix files from the Mac

BMERC : Index of needle software : Accessing Unix files


At BMERC as of 15 May 2000, our main file server, delbrueck, now understands Appletalk protocols. What this means is that you can now access files on your Unix account directly from the lab Macs. (The package that does this for us is called netatalk, if you're curious. Three cheers for Esther, who installed it!)

Table of Contents

  1. Accessing Unix files from the Mac
    1. Table of Contents
    2. Using delbrueck as a file server
      1. Benefits of direct Unix file service
      2. Starting it up
      3. Security considerations
      4. Shutting it down
    3. Tips and tricks
      1. Resource forks and the .AppleDouble directory
      2. Creating a Mac-specific directory
      3. The "Recent Servers" menu
    4. Frequently Asked Questions
      1. What about renaming, deleting, and copying files?
      2. How do I get access to other directories?
      3. How can I edit a Mac file on Unix?
      4. How can I edit a Unix file on the Mac?
      5. How can I find out who has open sessions?
      6. What is "AFP"?
      7. Why is it so slow?
      8. Why aren't my TreeView PICT files recognized?


Using delbrueck as a file server

Benefits of direct Unix file service

  1. You no longer need to use Fetch to move files back and forth between the Mac and Unix worlds (but Fetch is still useful; see below).
  2. You are no longer limited by the lack of disk space on the lab Mac in the corner.
  3. Macintosh files kept in your home directory tree will be protected with the usual Unix user password/file permission mechanisms (but see below).
  4. By the same token, Macintosh files in your home directory tree will automaticaly get backed up as part of the normal Unix backup schedule.
Although it is convenient to have all of your files available from both systems, most files will be specific to one system or the other. For this reason (and others described below), it is useful to segregate the Mac files from the Unix files by putting them in a directory of their own.

Starting it up

Here's how to open an AppleTalk session on delbrueck from a Macintosh:
  1. Bring up the Chooser (from the Apple menu), and click on the Appleshare icon. A list of Appleshare servers will appear in the list pane to the right.
  2. Click on the delbrueck entry in the list pane.
  3. Enter your Unix user name, e.g. "rogers", and password in the resulting dialog. Note: An odd quirk of this dialog is that it limits passwords to a maximum of eight characters. So, if your password is longer than that, you should type in only the first eight characters. Really, it is only the first eight characters that are significant to Unix in any case.
  4. If your password is correct, the Mac will start a session on delbrueck, and offer you one or more "volumes" or "shares" to mount. Whatever you want to call them, they correspond to Unix directories. By default, just your home directory is offered (but see below for how to change this).
  5. Once you confirm, the Mac will put an icon for each directory on the desktop.
That's it; you can now manipulate the files in your home directory in the Finder as if they were on the Mac. If this is your first time, you should consider the tip in the "Creating a Mac-specific directory" section, below.

Security considerations

[In case you were curious, I put this between startup & shutdown to make it hard to avoid reading. -- rgr, 15-May-00.]

Secure access to your files on delbrueck from a Macintosh is not much different from accessing them from another Unix machine:

You will only be able to access your files while you have an active session. So, if you leave the machine unattended without closing your session, all of your files can be deleted or defaced by anyone who walks by.
The important difference is that any random undergraduate or street person who wanders into the lab is more likely to know how to cause serious damage from a Mac console than from a Unix console. So, get into the habit of
shutting the connection down when finishing up work, breaking for lunch, etc.

Note that there is no penalty for closing the connection in the middle of working on, say, a Word document. You can close the connection with the Word document still open (don't forget to save first!), and then resume work on it later.

After you close a session, your login name will be listed under "Recent Servers" on the "Apple" menu. This is a convenience for frequent users, and does not pose a security risk, as the password is not stored. Hence, if you use the "Recent Servers" menu, you will be prompted for a password again.

Shutting it down

  1. Simply move your home directory icon to the trash, as if it were a floppy or Zip volume.
This closes the connection; re-opening it (as from the "Recent Servers" menu) will require re-entering the password.


Tips and tricks

Resource forks and the .AppleDouble directory

On nearly all operating systems, a file is essentially just a named collection of bytes; all else is mere detail (though the details are usually important). This is true for Unix systems, but it's not that simple for Macs. The Macintosh file system is unique on the planet for having two "byte collections" for each name, one called the "data fork", and one called the "resource fork". The Mac data fork contains what corresponds to what is normally thought of as "the file contents," and so netatalk stores the Mac data fork in the Unix file of the same name.

To store the resource information, the netatalk server creates a hidden directory called .AppleDouble in each directory that appears as a Macintosh "folder" in the Finder. The .AppleDouble directory contains one ordinary Unix file that holds the resource fork for each file of the same name in the parent directory, along with other information maintained by the Finder that doesn't fit the Unix file model. The most important example of this "other information" is the file type and creator IDs. The nature of the resource information depends upon the application that creates it, and can include such things as icons and font information. Not being a Mac hacker, that's about all I can tell you about it. (Another benefit of having a "Mac-specific" directory is that it reduces the .AppleDouble clutter, compared to having them scattered around your home directory tree.)

What happens if there is no .AppleDouble file? netatalk creates one with no resources, and with file type and creator based on the file extension.

Note that there are a few Mac-specific applications that put a great deal of information in the resource fork. Since doing so is inherently nonportable, these applications are generally either very Mac-specific to begin with, or are old versions from pre-Windows days. As far as I know, we haven't got any such applications at BMERC, but I could be wrong. In any case, if you delete the .AppleDouble content for such a file, the application will probably be unable to read or interpret the data fork, so be careful.

Creating a Mac-specific directory

If you already have a folder on the Mac, you can create a Mac-specific directory by copying your Mac folder into your Unix home directory folder. Do this in the Finder by dragging the icon for your Mac folder into your home directory. As a general rule, it is better to use the Finder (as opposed to Fetch) to copy files from the Mac to Unix, since that will also copy the resource fork for each file.

The "Recent Servers" menu

After you close a session, your login name will be listed under "Recent Servers" on the "Apple" menu, as mentioned in the
"Security considerations" section. If you pick from this list, then all you will need to supply is the password, thereby saving a few steps.


Frequently Asked Questions

Really, few of these questions have actually been asked, but it seemed easier to put this kind of miscellaneous information in question-and-answer format.

What about renaming, deleting, and copying files?

If you do this from Unix, the mv, rm, and cp commands won't know about the .AppleDouble files, so you will either need to deal with these files manually, or use the apple_mv, apple_rm, and apple_cp scripts. Remember that you might have to use quotes around characters in Mac file names that are meaningful to the shell.

If you forget and use the ordinary Unix rm command on the data file, the .AppleDouble file will be "orphaned." This is no big deal, as these files are usually small.

How do I get access to other directories?

By default, the Mac only offers to open your home directory when you start a session. If you would like to be able to access the whole disk, put the following lines (without indentation) in a file called .AppleVolumes in your home directory:
# The "/" means the file server root, which will be
# named "delbrueck" on the desktop.
/ delbrueck
# This means your home directory.
~
Note that your session runs as the user name you gave when you logged on, so your ability to read other users' directories and create files in them will be exactly the same as from a Unix shell when logged in using the same ID.

How can I edit a Mac file on Unix?

Unix and the Macintosh use different conventions for delimiting the end of a line in a text file. On Unix, lines are terminated by an ASCII LF (linefeed) character, whereas the Mac uses the ASCII CR (carriage return). A file created on the Mac therefore looks like one big line with embedded "^M" characters when viewed with most Unix tools, while a Unix file viewed on the Mac looks like one big line with embedded hollow-box characters (that being the graphic for "unknown character"). But
emacs is capable of bridging this gap.

When reading in a Mac file, emacs will notice that there are no linefeeds but tons of CR characters, and will assume the file is a Macintosh text file, automatically converting to its standard internal format. When this happens, you will see the string "--(Mac)--" (or some variation) at the left end of the mode line, instead of the usual Unix "--:--" string. When the file is written out again, the internal newlines will be converted back to Mac CR characters.

(emacs is also capable of dealing with DOS and Windows files, which end lines with both characters: CR LF. But that is another story.)

You can explicitly control the end-of-line encoding via the C-x RET f command (which is also available by menu as "Mule" -> "Set Coding System" -> "Buffer File"). Choose something like "undecided-mac" (completion works, so typing u TAB - m RET is sufficient), or maybe "iso-8859-1-mac", and the buffer will be written using that encoding the next time you save it. Note that this makes the file effectively useless in Unix; grep, not to mention all the other standard Unix tools, will treat the file as one big line with embedded "^M" characters.

Note that Fetch does this line-ending translation automatically when transferring ASCII files between the Mac and the outside world. Copying files in the Finder effectively uses binary mode, so Fetch still has a purpose in this brave new world.

How can I edit a Unix file on the Mac?

This is not likely to work, except in the following two cases:
  1. You have created the file as described in the "Editing Mac files on Unix" section (in which case, it is arguably not a Unix file); or
  2. You have created the file using an application (e.g. StarOffice, gimp) that uses a platform-independent file format such as .png (in which case, it is not a Unix-specific file).

How can I find out who has open sessions?

On delbrueck, do "ps -Af | fgrep atalk". The transcript will look something like this:
delbrueck> ps -Af | fgrep atalk
    root   266     1  0 13:19:47 ?        0:00 /usr/local/atalk/etc/afpd
    root   256     1  0 13:19:05 ?        0:00 /usr/local/atalk/etc/atalkd
  thread  2107   266  0 19:17:41 ?        0:00 /usr/local/atalk/etc/afpd
delbrueck>
The root/atalkd process is the listener for new Appletalk connections, the root/afpd process is the listener for new
AFP connections, while the thread/afpd process represents an actual server connection for the thread user.

What is "AFP"?

AFP stands for Apple File Protocol, which is a file-transfer and directory access protocol defined by Apple Computer. AFP is therefore analogous to NFS (defined by Sun Microsystems) or the Internet-standard FTP protocol.

Why is it so slow?

Unfortunately, the Macintosh in our lab is connected via an old Appletalk connection and a gateway, instead of directly via Ethernet, as is now standard for Mac installations. Both FTP and
AFP suffer from this bottleneck. If the Mac had a direct Ethernet connection, even 10baseT, file transfer speed would be in the megabyte/sec range.

Note that the term "Appletalk" describes three things: the original hardware and electrical interface specification (the "link layer"); the format of the packets that are transmitted over this hardware; and the set of software protocols that were first written for this hardware. The Appletalk protocols are faster over an Ethernet link than they are over the original Appletalk link hardware, and AFP is faster still using TCP/IP. File transfer speeds of up to 9.5 Mbyte/sec, close to the theoretical maximum, have been reported over 100BaseT using AFPoverTCP.

In fact, the server connection betwee delbrueck and the lab Mac does use AFPoverTCP, but the speed advantage of TCP/IP is negated by the slow hardware.

Why aren't my TreeView PICT files recognized?

Every time I try to open up a PICT file created by TreeView on Unix, the Mac thinks its a text file and tries to open it using SimpleText. How do I fix this?
This problem was discovered by Tom Plasterer. It turns out that TreeView is a very old program that uses a hack to supply Mac finder information in the first 128 bytes of the file. Tom wrote a Perl script to ditch the first 128 bytes, and reports that it works just fine; you can ask him for the script.

Another workaround is to copy the file to the Mac using Fetch, which apparently recognizes this old hack, and does the right thing with the 128-byte leader.


Bob Rogers <rogers@darwin.bu.edu>
Last modified: Thu Aug 3 13:20:52 EDT 2000