> AFP has served Apple well. It was simple and easy to use - and it was reliable. But since we live in a TCP/IP and Windows-based world now, it has outlived its usefulness.
What? Huh?
Since when does an open source project somehow stop working because an OS stops supporting whatever the project does?
Netatalk may very well become MORE relevant, because it may be the only way for Macs running the newest macOS to interact with older Macs.
And "TCP/IP and Windows-based"? Is this AI generated slop, or just a really bad author who doesn't understand technology? AFP has been able to use TCP/IP since at lease System 7.6.
Sigh.
It's sad, in part because it brought so many generations of Macs together. I have an iMac G3 motherboard built in to a Tonka truck that runs Mac OS X 10.4 Tiger and acts as a file server and can support m68k machines running System 7.6.1, all the way through Arm Macs running Sequoia 15.5. It's a good thing Netatalk exists!
> There's an NFS app for macOS called NFS Manager from Germany's Marcel Bresink.
> On pre-15.5 Macs, see the Terminal AFP command mount_afp by opening Terminal and typing:
> man mount_afp and pressing Return on your keyboard. To exit the man system, press Control-Z or the q key.
> Several third-party NAS vendors, such as Synology and others, include AFP support in their products, but that's likely to come to an end soon too.
(Not clear why it would be coming to an end if they’re based on Linux!)
The cached headline I saw on Mastodon also called it “depreciated”.
Losing AFP sucks, because macOS’s SMB support continues to be abysmally slow, and really needs Apple’s undocumented proprietary SMB extensions to work halfway decent. Lately I’ve been accessing my SMB shares (from both Samba and Windows 11) through Cyberduck, because Finder is just unbearably slow and gets tripped up on file permissions for no reason. Deprecated or not, Netatalk will be more important than ever if users need a protocol that just works.
DonHopkins•8mo ago
DonHopkins on June 21, 2022 | prev | next [–]
Another reason that NFS sucks: Anyone remember the Gator Box? It enabled you to trick NFS into putting slashes into the names of files and directories, which seemed to work at the time, but came back to totally fuck you later when you tried to restore a dump of your file system.
The NFS protocol itself didn't disallow slashes in file names, so the NFS server would accept them without question from any client, silently corrupting the file system without any warning. Thanks, NFS!
Oh and here's a great party trick that will totally blow your mind:
On a Mac, use the Finder to create a folder or file whose name is today's date, like "2022/06/21", or anything with a slash in it. Cool, huh? Bet you didn't think you could do that!
Now open a shell and "ls -l" the directory containing the file you just created with slashes in it name. What just happened there?
Now try creating a folder or file whose name is the current time, or anything with colons, like "10:35:43". Ha ha!
Don't worry, it's totally harmless and won't trash your file system or backups like NFS with a Gator Box would.
https://news.ycombinator.com/item?id=20007875
DonHopkins on May 25, 2019 | parent | context | favorite | on: Why Does Windows Really Use Backslash as Path Sepa...
There used to be a bug in the GatorBox Mac Localtalk-to-Ethernet NFS bridge that could somehow trick Unix into putting slashes into file names via NFS, which appeared to work fine, but then down the line Unix "restore" would totally shit itself.
That was because Macs at the time (1991 or so) allowed you to use slashes (and spaces of course, but not colons, which it used a a path separator), and of course those silly Mac people, being touchy feely humans instead of hard core nerds, would dare to name files with dates like "My Spreadsheet 01/02/1991".
https://en.wikipedia.org/wiki/GatorBox
Unix-Haters Handbook
https://archive.org/stream/TheUnixHatersHandbook/ugh_djvu.tx...
Don't Touch That Slash!
UFS allows any character in a filename except for the slash (/) and the ASCII NUL character. (Some versions of Unix allow ASCII characters with the high-bit, bit 8, set. Others don't.)
This feature is great — especially in versions of Unix based on Berkeley's Fast File System, which allows filenames longer than 14 characters. It means that you are free to construct informative, easy-to-understand filenames like these:
1992 Sales Report
Personnel File: Verne, Jules
rt005mfkbgkw0 . cp
Unfortunately, the rest of Unix isn't as tolerant. Of the filenames shown above, only rt005mfkbgkw0.cp will work with the majority of Unix utili- ties (which generally can't tolerate spaces in filenames).
However, don't fret: Unix will let you construct filenames that have control characters or graphics symbols in them. (Some versions will even let you build files that have no name at all.) This can be a great security feature — especially if you have control keys on your keyboard that other people don't have on theirs. That's right: you can literally create files with names that other people can't access. It sort of makes up for the lack of serious security access controls in the rest of Unix.
Recall that Unix does place one hard-and-fast restriction on filenames: they may never, ever contain the magic slash character (/), since the Unix kernel uses the slash to denote subdirectories. To enforce this requirement, the Unix kernel simply will never let you create a filename that has a slash in it. (However, you can have a filename with the 0200 bit set, which does list on some versions of Unix as a slash character.)
Never? Well, hardly ever.
Apparently Sun's circa 1990 NFS server (which runs inside the kernel) assumed that an NFS client would never, ever send a filename that had a slash inside it and thus didn't bother to check for the illegal character. We're surprised that the files got written to the dump tape at all. (Then again, perhaps they didn't. There's really no way to tell for sure, is there now?)