Subject: afpd quirkiness?

From: "Jay Plett" <[email-masked]>
Date: Tue, 16 Feb 93 14:01:10 EST

I have just installed netatalk 1.2.1 on a Sun4c running SunOS
4.1.3.  I started afpd with 3 Unix filesystems listed in its
afpd.conf file.  Each of the Unix filesystems contains a number
of directories, plus one plain-text file named "USERS".  When I
go to a Mac (Quadra 700) and bring up the menu for any of the 3
filesystems, I find that:
  - one of the directories is missing (has no corresponding icon)
  - there is a folder icon labelled "USERS"
  - that folder contains the contents of the missing directory
  - there is no textfile icon which produces the "USERS" file
Is this all as expected?  :-)

I guess my underlying question is: is netatalk, specifically
afpd, safe/desirable to run in a production environment?

Please reply directly to me as I don't receive this list.
Thanks a million.

	Jay Plett
	[email-masked]

---

From: [email-masked]
Date: Wed, 17 Feb 93 18:53:30 -0500

> From:    "Jay Plett" <[email-masked]>
> To:      [email-masked]

> Is this all as expected?  :-)

What a nasty bug you've found, Jay.  I've attached a patch to the end.
You may or may not want to apply it.  Let me explain where it comes
from.

First thing: The mac is a nasty machine and no one should use them.
This sort of implies that I think your problem is actually a bug on the
mac.  Specifically, I think it's a bug in the Finder, since both
ResEdit and MPW do not exhibit the same behavior.  Standard File seems
to have other related bugs, but I won't get into that...

Here's the problem:  Since the mac wants constant directory IDs, afpd
keeps an entry for each directory it's seen containing among other
things, the DID we've gave out to the mac.  There is another concept
associated with the mac file system called a file number (different
from a file ID).  Since (it seemed) the only requirement on FNUMs is
that they be unique in a directory, afpd returned the file's inode
number.  Well, turns out the Finder has an undocumented feature such
that the DID space and the FNUM space are really the same space; that
is, the Finder uses DIDs and FNUMs interchangeably.

So, what you were seeing, Jay, was a file whose inode number happened
to be 4, the same value as one of the sequencially assigned DIDs.
Before you apply this patch, you might try examining the directory with
an application that uses Standard File, just to verify that I'm right.

The solution that we've decided on, for the moment anyway, is to have a
global, "filenumber," which is initially set to 0xffff.  Each time the
mac asks for the filenumber, we de-increment the value of filenumber
and pass that back as the FNUM of the current file.  Now, it is
possible that over the course of a long session, filenumber can get
small enough that we'll have the problem again.

Another possible solution is to always set the high bit of the inode
number, on the assumption that there will never be more that 2.1
billion directories opened.  This solution also has the drawback that
you can never really tell how your system has assigned inode numbers,
so you could have two files that collide.  Either solution is pretty
easy for us to implement, so if anyone has strong feelings either way,
let me know.

One last note, CAP's AUFS uses a scheme very similar to ours to assign
DIDs and FNUMs, so it should give very similar results.  (Add 320, I
think.)

> afpd, safe/desirable to run in a production environment?

No, but we do, and neither is CAP, so I guess I'm not too worried. :)
But really folks, what does safe mean?  Is SunOS safe?  We've been
running afpd here for years and I've never seen this bug (thanks for
pointing it out, BTW).

wes

--- cut ---
*** etc/afpd/file.c-	1992/12/03 23:04:11
--- etc/afpd/file.c	1993/02/17 23:23:33
***************
*** 49,54 ****
--- 49,56 ----
      0, 0, 0, 0, 0, 0, 0, 0,
  };
  
+ int		filenumber = 0xffff;
+ 
  getfilparams( bitmap, path, dir, st, buf, buflen )
      u_short	bitmap;
      char	*path;
***************
*** 144,150 ****
  	    break;
  
  	case FILPBIT_FNUM :
! 	    bcopy( &st->st_ino, data, sizeof( int ));
  	    data += sizeof( int );
  	    break;
  
--- 146,153 ----
  	    break;
  
  	case FILPBIT_FNUM :
! 	    filenumber--;
! 	    bcopy( &filenumber, data, sizeof( int ));
  	    data += sizeof( int );
  	    break;