Netatalk / netatalk

Netatalk is a Free and Open Source AFP fileserver. A *NIX or BSD system running Netatalk is capable of serving many Macintosh clients simultaneously as an AppleShare file server.
https://netatalk.io
GNU General Public License v2.0
327 stars 84 forks source link

Reintroduce AppleTalk / DDP support #220

Closed rdmark closed 1 month ago

rdmark commented 1 year ago

To investigate the feasibility and break down the requirements for reintroducing the AppleTalk into the main Netatalk development branch.

Background

AppleTalk / DDP and associated daemons and tooling were deprecated with Netatalk 3.0, in order to streamline the codebase and making it more maintainable / extendable. Fast forward a few years, and AFP over TCP has become a legacy protocol with Apple switching to SMB as the file sharing protocol in macOS since Maverick. This changes the equation for Netatalk in two notable ways: 1, no need to continuously iterate on the capabilities as Apple adds new functionality, and 2, the primary value of Netatalk becomes to support vintage Mac networks. In this context, reinstating AppleTalk makes sense.

Solutions

Two approaches can be considered

  1. Add atalkd code back to Netatalk 3.1
  2. Backport all Netatalk 3.1 improvements to Netatalk 2.2

Pros with option 1

Cons with option 1

Pros with option 2

Cons with option 2

Requirements

rdmark commented 1 year ago

In the case of option 1, I went through the 2.x code tree and picked out modules that I think should be brought over, and a few that I think are safe to discard. Just to get an idea of the scope of effort.

Save

Optional

edit: updated for the state of v2.4

ghost commented 1 year ago

Hi @rdmark, you're doing some great work reviving Netatalk and giving a future for Vintage Mac networks. I have created a fork that allows networking and file sharing between vintage Macs running Mac OS 9 and modern Intel/Apple Silicon Macs that do not support AFP over TCP. Feel free to implement any changes from there that you see fit :) https://github.com/dgsga/netatalk

rdmark commented 1 year ago

@dgsga Well thank YOU for doing the same, really! This is truly a community effort, keeping Netatalk alive. If there is any clear cut improvement that you think would be helpful upstream, don't hesitate to throw a PR this way! You may be the best person to judge whether something is generally useful, or specific to macOS compatibility.

rdmark commented 1 year ago

Glancing through the main branch commit log in 2011 - 2012: two things that may need more plumbing to restore are encodings (conversion from classic Mac code pages), and support for AFP 2.

The deprecation of DDP seems to have started in earnest with https://github.com/Netatalk/netatalk/commit/d5945415631bb4568400fc55e3095259938c979d

This is a good starting point I think. https://github.com/Netatalk/netatalk/commits/main?after=f76299185252a7505e504e102d157ecd69b437da+1434&branch=main&qualified_name=refs%2Fheads%2Fmain

NJRoadfan commented 1 year ago

Option 1 likely makes sense from a code maintainability point of view.

The biggest feature from that I would like to see from Netatalk 3.x is using OSX style EAs. This is key if you intend on sharing the same folders under Samba. Right now using Netatalk 2.x and accessing the same shares via SMB on macOS is going to lead to a ton of headaches and lost resource forks.

Moving to INI style config scripts for all the "legacy" services (mainly papd, and atalkd) would likely be the biggest hurdle. A lot of legacy AFP 2.x protocol support is still present in the 3.x tree.

rdmark commented 2 months ago

Additional requirement:

Forward-porting support for AppleTalk-only AFP protocol versions. There are branches sprinkled across the codebase that checks for AFP version number and returns different data.

AFP 1.1 AFP 2.0 AFP 2.1
Version String AFPVersion 1.1 AFPVersion 2.0 AFPVersion 2.1
Client (roughly) early Mac? Apple II, System 6.0 System 7.0, 7.1
Server early personal file sharing? AppleShare 2.0 AppleShare 3.0

Edit: Updated for accuracy

NJRoadfan commented 2 months ago

Apple II support (namely the ProDOS attribute support) was introduced in AFP 2.0. Both the Apple IIgs and IIe Workstation clients are AFP 2.0. "Inside AppleTalk" goes into the differences between 1.1 and 2.0, which aren't all that different besides the Apple II support.

rdmark commented 1 month ago

First roadblock encountered: This commit https://github.com/Netatalk/netatalk/commit/fb751e80c0bc12c35675fbf1434ceecb4aad47cb removed support for ASP and PAP child process handling, rewriting it as AFP-only. Very mildly used in asp_getsess.c ...

NJRoadfan commented 1 month ago

Obsolete volume options (prodos, size limit, etc.) need to be added back in and reworked for the new INI configuration system. These options were removed in this commit https://github.com/Netatalk/netatalk/commit/863882cb7af7d0bd2651f957b155fd5aa9e2d9d6

Only some of these are actually important. The automatic CR/LF handling can be ignored.

rdmark commented 1 month ago

@NJRoadfan Thanks for the suggestions. We don't need mswindows either I believe. I'm pretty sure it was part of the ancient "SFM" compatibility layer via a modified Samba version lost to time.

NJRoadfan commented 1 month ago

The mswindows options appears to be for clients. DOS and Windows AFP clients can't handle several characters in file names that are legal on Macintosh.

NJRoadfan commented 1 month ago

Additional Note on volumes: Netatalk 3.x no longer creates several "special folders", likely because they are not used by OS X. These are TheVolumeSettingsFolder, TheFindByContentFolder, "Temporary Items", and "Network Trash". None of these seem to work properly on netatalk 2.x anyway due to permissions issues (they are created as owned by root by default).

rdmark commented 1 month ago

All of the relevant code has been committed to main now, with scaffolding for the build system set up. The code does not yet compile, mainly because of the aforementioned child process handling, so AppleTalk is disabled by default in the build system.

Further work has been branched off into new tickets with the appletalk issue label.