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.