Why I'm sticking with AFP

[Constantin]

Apple has been deprecating AFP in favor of SMB for a long time now. I was under the impression that AFP had been removed for Mojave (10.14) and hence waited for @anodos and all the other fine folk here to enable and test out SMB-based Time Machine and like OSX specifics. I then made the first switch, initially successfully converting a time machine share from AFP to SMB for use in Sierra (10.12). That worked, at least initially.

I then took the plunge, converting more shares and finally upgrading my machine to Mojave. The most significant issue I encountered is that AFP allows a wider character-set as well as file-name path length than SMB does. Filenames got mangled. Worse, some things simply could no longer get copied to external backup storage due to the file name being too long. Curiously, the SMB Time Machine share also became unhappy over time and the OS would quit the backup with a -65 error.

The good news is that AFP is in fact still supported by Mojave. So, I re-instated all the AFP shares, re-arranged some mount points and directories to make routine synchronizations faster (i.e. segregate the truly dormant stuff) and called it a day. For me, AFP still seems like a better way to share data between a Mac and a FreeNAS unless you can scrupulously follow the limits imposed by SMB, such as <255-character file-name paths.

Speaking of which, does anyone know of a utility that can flag where there are instances of file names that are illegal and/or too long for a given file transfer protocol? Could that be an interesting tool for FreeNAS to incorporate?

 

[jgreco]

Apple started its long slow decline away from attempting to be technically excellent years ago. Many examples both big and small, ranging from a half decade to update some of the Macs (including the Mac Pro), to the deprecation of AFP and abandonment of both the server hardware and software. The netatalk project has struggled under this ambiguity for quite some time, I think, and it's pretty tragic how things have wound up.

 

[Constantin]

Apple gave up on the EDU market as well as the pro stuff and focused instead on iOS/iPad/iWatch, the cloud and assorted services.

Hard not to when the business side gave them little love in return for the server-oriented gear (which was decent for the time). Apple did itself no favors just discontinuing stuff overnight or cutting back OS X server more and more with every new edition. Google ate them up via chromebooks, Google Docs, and the weird promise that someone holding on to your data in the cloud was a good idea.

To me, Google docs has all the appeal of tooth surgery. No auto-iterating captions under figures and tables? No proper TOC, section numbering, etc. support? Even Word 5 did considerably better in 1988 than this... but of course Word 5 didn't have the ability to process inputs from a wide number of users at once. Building even a semi-capable word processor in a browser window is a stunning technical achievement but the current document I'm working on will eventually have to be imported into Word for post-processing (i.e. make it presentable, proper TOC, and so on) once all the necessary content has been added.

Anyhow, I'm happy I can still use AFP in 11.2 with Mojave. It saves me considerable headaches not having to hunt down content that SMB mangles and vice versa.

 

[anodos]

Speaking of which, does anyone know of a utility that can flag where there are instances of file names that are illegal and/or too long for a given file transfer protocol? Could that be an interesting tool for FreeNAS to incorporate?

For SMB, you can adjust share level parameters as follows:

Code:

1) add catia vfs module
and
2) add follow share parameters auxiliary parameters:
mangled names = no
fruit:encoding = native

This combination of parameters will improve compatibility for invalid characters.

 

[Constantin]

Thank you, anodos! I’ll have to remember your post for the time I try to go back to SMB!

However, I presume the SMB 255-character file path name limit length is here to stay?

 

[anodos]

Thank you, anodos! I’ll have to remember your post for the time I try to go back to SMB!

However, I presume the SMB 255-character file path name limit length is here to stay?

That's a Win32API limitation, not an SMB limitation

Code:

smb: \ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\> put cygwin.pcap.pcapng 
putting file cygwin.pcap.pcapng as \ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\cygwin.pcap.pcapng (1422.5 kb/s) (average 1422.5 kb/s)
smb: \ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\> ls
  .                                   D        0  Tue Dec 24 21:50:20 2019
  ..                                  D        0  Tue Dec 24 21:47:06 2019
  cygwin.pcap.pcapng                  A    17480  Tue Dec 24 21:50:20 2019

        2714280 blocks of size 1024. 2007192 blocks available
smb: \ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\ACETYLMETHYLCARBINOL\>

 

[Constantin]

I ran into that limitation using rsync (via CarbonCopyCloner) and SMB . Lots of files could not be copied because their paths were allegedly too long.

Once I switched back to AFP, the problem went away. Is this a bug in CCC?

 

[anodos]

I ran into that limitation using rsync (via CarbonCopyCloner) and SMB . Lots of files could not be copied because their paths were allegedly too long.

Once I switched back to AFP, the problem went away. Is this a bug in CCC?

Possibly. You'd have to look carefully at what samba is reporting in its logs when there's a failure. Sometimes information gets lost in the transition from Unix errno -> NT_STATUS -> MacOS error. It may also be a limitation in the MacOS SMB client.