*The OS X server doesn't support ProDOS-type file type info, so trying to set it will give an error. This normally causes GS/OS to give an error when creating a file. There is now an option to ignore the error and proceed with creating the file, although the file type still won't be set.
*The OS X server seems to restrict each write operation to a small size based on the ASP quantum, so there is now an option for this. Using this option means we may write less than requested, but the AppleShare FST can detect this and proceed to write the rest.
This tells the server to keep the session alive (typically for at least several hours) without sending or expecting tickles. This is useful in cases where our run queue procedure is not run regularly or at all, e.g. in text-mode shells.
The implementation here is geared toward compatibility with Netatalk and differs from Apple's published standards in a couple ways. It may or may not work with other servers.
This avoids any possible strange behavior with calling Marinetti in P8 mode. It also ensures that I/O operations in P8 mode will give an error, but not terminate the connection: it will still be alive when we get back to GS/OS, unless the server has killed it due to inactivity (which is quite possible).
This can occur when control-reset is pressed in P8 mode. It’s supposed to reinitialize the AppleTalk stack. In our case, we mark connections to be reset once we're back in GS/OS, since we can't call Marinetti in P8 mode.
This only works if our init is loaded before Marinetti’s, because otherwise Marinetti’s shutdown notification procedure gets control first and shuts down the connection.
This should add support for a greater variety of servers, which may only support AFP 2.2 and up (or refuse to use older versions over TCP).
The IIgs software is designed for AFP 2.0. AFP 2.2 is close enough that things seem to work, but there could potentially be a few compatibility issues.
This could be unsafe for some forms of client code, but it looks like the AppleShare FST always actually has a large enough buffer to hold the full amount being requested, and can deal with up to 65535 bytes being returned at once. We take advantage of this to do larger reads in a single request, which provides a noticeable performance advantage.
This patch disables asynchronous SPCommand calls to work around the problem, which was causing hangs and crashes when those calls triggered. This effectively prevents the FST from automatically polling to check if the volume has been changed, but shouldn't cause other problems.
This issue arises because ASP requests and replies are limited to a “quantum size” of 4624 bytes even if the amount requested is larger, and the AppleShare FST relies on this behavior in sizing its buffers. DSI does not have this limitation, so it was returning more data than would fit in the buffer.
Also improve error checking, so an error is reported in cases where the buffer is too small.
Stephen Heumann