Subject: Sharing CD-ROM's and Floppy's via NetaTalk

From: Stefan Srdic <[email-masked]>
Date: Sun, 04 Feb 2001 09:05:23 -0700

I've recently configured an old Pentium to serve as a Apple file server
on a simple peer-peer network. I have been requested by my client to
configure the Linux box so that he would be able to mount floppies and
CD-ROM drives over the network. How do you accomplish this?

So far, the user is able to log into the Linux box and mount his home
diretory over the network. How do I give permissions to this user and
configure NetaTalk so that he can mount floppies and CD-ROM's?

Thanks

Stef

---

From: "Philip B. Bechtel" <[email-masked]>
Date: Sun, 04 Feb 2001 19:44:02 -0500

Stefan,

    I used Supermount to allow the CDs to be mounted.  It worked ok for
most files, but never was satisfactory for Mac executables.
The reason was that the date/time information that Linux offered to the
Mac clients, was almost always out-of-order, and the software
would refuse to work.

Good Luck, and let me know if it works.  It was a long time ago, that I
used netatalk to serve CDs to Macs, I hope the date/time
information has been corrected, kernel 1.3.

Phil

--
- Philip B, Bechtel                                                    -
- AARDSYS,LLC                         "The earth is but one country    -
- (716) 778-5271                       and mankind it's citizens."     -
- [email-masked]                -- Baha'u'llah                -

---

From: Carsten Neumann <[email-masked]>
Date: Mon, 5 Feb 2001 02:11:26 +0100

> information has been corrected, kernel 1.3.

I think the bigger problem is that your resource fork and finder info will get dropped.
Afpd uses the .AppleDouble dir to store these things, i.e. one extra file per mac file.
An HFS volume (or ISO9660 w/HFS extension) stores these in two separate directories .finderinfo and
.resource, i.e. two extra files per mac file.
They aren't seen by afpd.
So you only have access to the data fork, which is sometimes not enough. ;-)
Or is there an option to mount HFS volumes that they can properly be used via afpd?
Or an option for afpd?

> > configure NetaTalk so that he can mount floppies and CD-ROM's?

Regards

	Carsten

---

From: Bill Moran <[email-masked]>
Date: Sun, 04 Feb 2001 23:07:40 -0500

> Or is there an option to mount HFS volumes that they can properly be used via afpd?

There is a suite of HFS tools for FreeBSD that allow mounting of HFS
volumes (including CD-ROMs, etc) I'd assume that they're available under
Linux, but I don't know. I also don't know the extent of their
capability. It's something to look into, though.

-Bill

---

From: "Philip B. Bechtel" <[email-masked]>
Date: Mon, 05 Feb 2001 00:16:44 -0500

The hfs module was available back when I tried it.  It certainly did provide the forked files that
were on the Mac CDs. I believe I
copied executables from a Mac CD on a Mac to a Netatalk share and it would then be executable if the
software didn't check the
date/time for some kind of weak copy protection.  Some programs worked fine, others didn't.  It was a
few years back, so trying it again,
by copying a complete executable from the Mac to a netatalk share, testing execution, then mount the
CD with HFS module loaded, and try execution again to see any difference, would be useful.

Phil

---

From: Carsten Neumann <[email-masked]>
Date: Mon, 5 Feb 2001 06:23:22 +0100

On Sun, 04 Feb 2001, Stefan Srdic wrote:
> Would compiling Apple FileSystem support in the new 2.4 kernel solve this problem? If so, would it be
> recomended to partition a seperate directory under the Apple File System for use with NetaTalk?
> 
> Stef

I have HFS support as module, think there is no difference between kernel-integration and module.
I also think there is no change from 2.2.x to 2.4 regarding HFS.
If you haven't already, compile Apple filesystem support into your kernel or as a module.
So you will be able to mount HFS images.
But that wouldn't solve our problems.
If you mount an HFS image like:

mount -t hfs -o loop disk.img mount-point

there will always be the .finderinfo and .resource directories instead of the .AppleDouble dir.
So afpd doesn't see it -> no resource fork, file type, creator, etc.

Could be a challenge to have afpd work on Mac HFS. :-)
I sometimes dreamed of mounting my jukeboxes CDROMs remotely via AppleTalk. :-))

If someone has knowledge and time to make afpd mess around with the .resource and .finderinfo files
this would be a great advance.

Regards

	Carsten

---

From: Carsten Neumann <[email-masked]>
Date: Mon, 5 Feb 2001 05:54:22 +0100

> capability. It's something to look into, though.

There is a program suite which is called hfsutils, it contains programs as:

       hattrib - change HFS file or directory attributes
       hcd - change working HFS directory
       hcopy - copy files from or to an HFS volume
       hdel - delete both forks of an HFS file
       hdir - display an HFS directory in long format
       hformat - create a new HFS filesystem and make it current
       hls - list files in an HFS directory
       hmkdir - create a new HFS directory
       hmount - introduce a new HFS volume and make it current
       hpwd - print the full path to the current HFS working directory
       hrename - rename or move an HFS file or directory
       hrmdir - remove an empty HFS directory
       humount - remove an HFS volume from the list of known volumes
       hvol - display or change the current HFS volume
 
       hfssh - Tcl interpreter with HFS extensions
 
       hfs - shell for manipulating HFS volumes
       xhfs - graphical interface for manipulating HFS volumes

This is also available for linux.

But with that you cannot really mount a HFS volume into your filesystem.
"hmount" rather means: remember in a text file that on device (partition) /dev/<somewhat>
there is a volume called <volume-name>.
"hcd" means: remember, you last visit <directory> on last volume (you have separate working dirs on
each of the "mounted" volumes).
Etc.
You ALWAYS access the HFS volumes DIRECTLY via the hfsutils (raw i/o on the device).

Since the Mac volume isn't really mounted at some mount point, afpd will never see it.
These utils are solely designed to access Mac HFS volumes via commandline (or wrappers).

I just remember:
The utils mdir, mcopy, etc are the mess-dos pendants for that.
I never had to deal with them. :-)

Regards

	Carsten