mirror of
https://github.com/mabam/afpfs-ng-mac.git
synced 2025-01-06 01:32:09 +00:00
267 lines
8.6 KiB
Plaintext
267 lines
8.6 KiB
Plaintext
|
|
Some compatibility details for afpfs-ng 0.8, February 18, 2008.
|
|
|
|
|
|
A. Login methods
|
|
----------------
|
|
|
|
The following UAMs are implemented:
|
|
- Cleartxt Passwrd
|
|
- No User Authent
|
|
- Randnum Exchange*
|
|
- 2-Way Randnum Exchange*
|
|
- DHCAST128*
|
|
- DHX2*
|
|
|
|
However, only those with a (*) will exist if you build with libgmp and
|
|
libgcrypt. By default, Mac OS X 10.5 and later only support those with a (*).
|
|
It is possible to enable cleartext passwords in those versions, but this is
|
|
not a great idea.
|
|
|
|
The following UAMs have not yet been implemented:
|
|
- kerberos, this requires integration with a KDC
|
|
- reconnect, it is a bit unclear how this should be done with session keys.
|
|
This isn't properly described in the docs. It also isn't really a UAM.
|
|
|
|
Password changing isn't implemented, although it has been roughed in.
|
|
The interface would be in afpcmd.
|
|
|
|
There is no support for open directory.
|
|
|
|
'status' will show you what UAMs are compiled in and what is being used.
|
|
|
|
B. Connect, disconnect
|
|
----------------------
|
|
|
|
There are basic facilities to receive and send session keys, but these are not
|
|
used.
|
|
|
|
Server disconnect and reconnect isn't currently working. Right now, there's a
|
|
random token that gets sent, but that's it.
|
|
|
|
The client doesn't recover if the server goes down partway through a transaction.
|
|
|
|
C. UID and GID mapping
|
|
----------------------
|
|
|
|
One area of complication is around UID and GID mappings. These may differ
|
|
between the client and server. There are two modes that are enabled in
|
|
afpfs-ng:
|
|
|
|
1. Common user directory
|
|
|
|
This is where both the client and server have
|
|
identical UIDs and GIDs. This is the case where you have an NIS server
|
|
between them, or some other common directory.
|
|
|
|
2. Login IDs
|
|
|
|
This is where all the files appear as the user that logged in. This would
|
|
typically be used where the databases are separate, and one user expects to
|
|
be able to read/write all the files he sees. This can get confusing, since
|
|
any files that aren't his will appear to be owned by him, but writing to
|
|
them will result in an EPERM.
|
|
|
|
3. Named mapping
|
|
|
|
This is where the name (not uid) of the owner is mapped correctly. This is
|
|
not implemented.
|
|
|
|
4. Mapping from file
|
|
|
|
This is where a file is read that translates client and server ids. This is
|
|
not implemented.
|
|
|
|
afpfs-ng attempts to detect the mapping type automatically; do 'afp_client
|
|
status' (for FUSE monts) or 'status' within afpcmd to see what it guessed.
|
|
|
|
|
|
D. Meta information
|
|
-------------------
|
|
|
|
1. Server icon
|
|
|
|
A readonly copy of the server icon can be found in /.servericon.
|
|
|
|
2. Resource forks
|
|
|
|
Every directory has a hidden directory called .AppleDouble, and if a resource
|
|
fork exists, you'll find it there. As an example, the resource fork for
|
|
/foo/bar/testfile can be found in /foo/bar/.AppleDouble/testfile.
|
|
|
|
The permissions of the resource fork are the same as the data fork.
|
|
|
|
3. Desktop functions
|
|
|
|
a) Comments
|
|
The only desktop function that's actually implemented is comments. For file
|
|
/dir/foo, they can be found in /dir/.AppleDouble/file.comment
|
|
|
|
Permissions for the comment are the same as the data fork.
|
|
|
|
b) Catalog searching
|
|
c) Icon searching
|
|
d) APPL
|
|
|
|
None of these are really suitable as a filesystem. But you could get access
|
|
to them if you wrote your own client.
|
|
|
|
4. Finder info
|
|
|
|
Finder info for files and directories for /dir/foo can be found in
|
|
/dir/.AppleDouble/foo.finderinfo.
|
|
|
|
|
|
E. ACLs and extended attributes
|
|
-------------------------------
|
|
|
|
ACLs and extended attributes have not been implemented.
|
|
|
|
|
|
F. Internationalization
|
|
-----------------------
|
|
|
|
For servers that support it, UTF8 usernames, server names, volume names and files are supported.
|
|
|
|
Older clients (Mac OS 9) that don't use filenames of type long. Other
|
|
charsets for files (MacRomanian, etc) are not supported properly. Servernames
|
|
are supported.
|
|
|
|
G. Networks
|
|
-----------
|
|
|
|
IPv6: There is no support for IPv6.
|
|
Appletalk: There is no support for Appletalk
|
|
IPv4: Yes, of course.
|
|
|
|
There's no concept of multiple protocols, eg. doing getstatus with one protocol,
|
|
then connecting with another, which is what some Apple clients do.
|
|
|
|
There's no ability to connect based on a name advertized by Bonjour/Avahi, you
|
|
need to use the IP or DNS name.
|
|
|
|
|
|
H. Server-specific information
|
|
------------------------------
|
|
|
|
afpfs-ng detects the server type by parsing the Machine Type field in
|
|
getstatus. The command line 'afpgetstatus' will show this without you having
|
|
to log in. 'status' will show you this also.
|
|
|
|
The detection is done in order to deal with some details.
|
|
|
|
1. Mac OS 8
|
|
|
|
afpfs-ng has never been used with Mac OS 8, so there's no data. You could do
|
|
this with AFP over TCP/IP, but this could be difficult. Email me if you have any info.
|
|
|
|
2. Mac OS 9
|
|
|
|
This speaks AFP 2.1, so this presents certain restrictions, such as:
|
|
- smaller limits on file and disk sizes (4GB)
|
|
- creating files larger than 2GB isn't possible and isn't handled properly
|
|
- 'df' will report a max of 4GB.
|
|
- no support for Unix privileges; all files are reported as 0600, directories
|
|
as 0700.
|
|
- for directories, timestamps are reported as the mount times, which is what
|
|
the Mac OS X client does.
|
|
|
|
There is no proper charset conversions for filenames. Patches accepted.
|
|
|
|
This has been lightly tested.
|
|
|
|
3. Mac OS X
|
|
|
|
Various versions have been tested, including 10.2, 10.3, 10.4 and 10.5.x. This has been most
|
|
heavily tested. Note the restrictions on UAMs above.
|
|
|
|
10.5 introduces AFP function 76, but there's no documentation on this. Too
|
|
bad.
|
|
|
|
4. Airport Extreme
|
|
|
|
The airport extreme with firmware 7.1 and 7.2.1 has been tested, and has two
|
|
oddities:
|
|
|
|
- Unix permissions aren't handled at all
|
|
|
|
- the device has a software bug which can let an authenticated user freeze the
|
|
device. I won't describe the problem in any more detail. Apple has
|
|
acknowledged the problem, but hasn't yet released updated firmware.
|
|
|
|
Note that the Airport can serve up SMB and AFP disks; afpfs-ng only handles
|
|
AFP.
|
|
|
|
5. Time Capsule
|
|
|
|
The Time Capsule is a network backup device meant to handle Time Machine
|
|
backups over AFP. This hasn't been released and my wife won't let me buy one,
|
|
so there's been no testing. Donations appreciated.
|
|
|
|
6. Netatalk
|
|
|
|
This open source server has a few issues, and afpfs-ng tries to work around
|
|
them. The most significant one is around file permissions; there's a bug in
|
|
older versions whereby some permissions cannot be set with a chmod (particularly
|
|
the execute bit on files).
|
|
|
|
It becomes a bit difficult to identify if you have the newer or older version
|
|
of netatalk since it has been changed in CVS, and occurred after 2.0.3. 2.0.4
|
|
hasn't been released yet (almost 3 years later). Some distributions (such as
|
|
Fedora 8) ship a broken version.
|
|
|
|
There's a patch available on the afpfs-ng download site, although grabbing a
|
|
later version of netatalk from CVS will work also.
|
|
|
|
After you attempt to 'chmod +x foo', 'status' will show you if it is broken or
|
|
not.
|
|
|
|
7. LaCie devices
|
|
|
|
The LaCie device has an ARM processor in it, and speaks netatalk. Part of the
|
|
problem with that some login crypto is so slow that older versions of afpfs-ng
|
|
timeout before the server can complete the crypto. This should be fixed as of
|
|
0.8, but this hasn't been tested properly.
|
|
|
|
|
|
I. FUSE-specific bugs
|
|
---------------------
|
|
|
|
There are no facilities for automounting home directories, which is something
|
|
that people ask for frequently. This requires having integration into open
|
|
directory.
|
|
|
|
There are some bugs around race conditions that can make heavy load operations
|
|
(eg. compiling a kernel) freeze or stall.
|
|
|
|
Testing has been done based on FUSE 2.7.0.
|
|
|
|
J.Other
|
|
-------
|
|
- length of file is currently fixed at 255; this isn't correct for AFP >3.0
|
|
|
|
K. References
|
|
-------------
|
|
|
|
Not all references are easy to find. The useful ones are:
|
|
- Apple Filing Protocol Programming Guide, Version 3.2, 2005-06-04
|
|
- AppleTalk Filing Protocol, Versions 2.1 and version 2.2., Apple Computer Inc, 1999
|
|
- Inside Macintosh, Macintosh Toolbox Essentials, 1992
|
|
|
|
And other software:
|
|
- netatalk: Netatalk is the server side, and it implements AFP 3.1 over
|
|
Appletalk and TCP/IP. It has a long history and has been heavily tested, but
|
|
is creative in some of its implementation.
|
|
|
|
- afpfs: The original afpfs was last release for Linux kernel 2.2.5 and was
|
|
written in kernel space. It was written by Ben Hekster, then taken over by
|
|
David Foster. I think it was last maintained in 1999 and only handled AFP 2.x.
|
|
Truly, afpfs-ng was intended to take over where they left off, but this is a
|
|
complete rewrite in order to fit into FUSE.
|
|
|
|
- hfsplus: This might not seem related, but the way that hfsplus handles
|
|
presenting resource forks to userspace may be relevant to how afpfs-ng does
|
|
the same.
|
|
|
|
- wireshark (aka ethereal): the AFP packet parsing is excellent
|