Technical Note NW510

AppleTalk Filing Protocol Q&As

CONTENTS AFP error codes -5060,-5061, -5062, and -5063 How an AFP volume's allocation block size is calculated Inside Macintosh Volume VI PBGetVolMountInfoSize typo AFP 2.0 FPRead NewLine Mask change Downloadables

This Technical Note contains a collection of archived Q&As relating to a specific topic - questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site. [Oct 01 1990]

AFP error codes -5060,-5061, -5062, and -5063

Date Written: 1/18/93

Last reviewed: 6/14/93

What's AppleTalk error -5062? It seems to be an AppleTalk Filing Protocol error of sorts but I can't find it documented anywhere.

Error -5062 is an afpAlreadyMounted error. You'll get it from the AppleShare external file system if you try to mount an AppleShare volume that's already mounted with PBVolumeMount. The three PBVolumeMount-related functions were added to System 7 very late during development, so afpAlreadyMounted (-5062), afpBadDirIDType (-5060), afpCantMountMoreSrvrs (-5061), and afpSameNodeEr (-5063) never made it into the public interface files.

References:

Inside Macintosh Volume VI, pages 25-49 and 25-50

Back to top

How an AFP volume's allocation block size is calculated

Date Written: 8/15/91

Last reviewed: 8/16/91

The AppleTalk Filing Protocol (AFP) doesn't appear provide a way to learn about the allocation block size of a server volume. So, how is the allocation block size determined on AFP server volumes? I noticed that the Macintosh Finder seems to calculate "size on disk" erratically for files on some AFP server volumes. Is that a related problem?

All the workstation can get from an AFP server is the Bytes Total and Bytes Free (returned by FPGetVolParms and FPOpenVol), so the AFP workstation code estimates the value it uses in the allocation block size field (vcbAlBlkSiz) of the volume control block (VCB). The workstation code comes up with a value for vcbAlBlkSiz from the Bytes Total value returned to FPOpenVol when the volume is opened. The calculation used is:

This is the same value a local HFS volume would use. If an AFP server is not running on a Macintosh (and then, probably not using HFS), then this value may not be what the server platform is actually using. And yes, the Finder uses the allocation block size in its calculations to decide how much space is used by a file, so the "size on disk" may not exactly reflect the amount of disk space actually used.

Back to top

Inside Macintosh Volume VI PBGetVolMountInfoSize typo

Date Written: 1/22/92

Last reviewed: 6/14/93

When I call PBGetVolMountInfoSize to get the size of an AppleShare volume's mounting information record, the function returns with no errors but ioBuffer points to garbage instead of the size of an AFPVolMountInfo record.

The problem you're having with PBGetVolMountInfoSize is a typo in Inside Macintosh Volume VI on page 25-48. In that call, the ioBuffer field should be a pointer to a word (2-byte) size variable, not a long (4-byte) size variable.

Back to top

AFP 2.0 FPRead NewLine Mask change

Date Written: 5/3/89

Last reviewed: 11/21/90

I'm confused about the changes to FPRead in AFP (AppleTalk Filing Protocol) version 2.0. How do I use the NewLine Mask?

The difference between AFP 1.1 and AFP 2.0 as far as the NewLine Mask is concerned is that, in AFP 1.1, the only legal values of NewLine Mask are $00 and $FF, whereas in AFP 2.0, all values of NewLine Mask are allowed. The NewLine Mask is logically ANDed with a copy of each byte read. If the result matches the NewLine character, the read terminates. The NewLine character is returned as the last byte of data that was read from the fork.

Back to top

Downloadables

Back to top