On Sunday, November 18, 2012 8:29:20 PM UTC-6, schmidtd wrote:
> On 11/18/2012 4:34 PM, Kevin wrote:
> > put states
> > Apple sends:
> > One byte: "Z" ($DA)
> > Byte stream: file name (null terminated)
> > Host sends:
> > Two bytes: file size in blocks (LSB, MSB)
> > One byte: return code:
> > $00 = File exists (and file size is valid)
> > $02 = File does not exist
> > $04 = File exists, not recognized as a valid disk image
> > if the disk is coming from the apple how is the host going to find a file, measure its size and check for being valid?
> Some history for you: in the beginning there was ADT, and there was only
> the "S" flow to send a disk. It unconditionally sent the file, with no
> concern as to whether or not the file existed on the host. It would
> fail with unable to write, or overwrite without confirmation; I don't
> remember which, but both situations were bad.
> ADTPro came along, and "P" was introduced. That essentially implemented
> the same (broken) semantics, though the flow has different contents. It
> positively overwrote whatever happened to be there with the same file name.
> So an extension was born: the "Z" flow. This is all transparent to the
> user; the Z and P are combined into one logical flow. You'll see both
> mushed together on the protocol section just below what you cited. What
> happens with "Z" is that the proposed filename is sent to the host, and
> the host replies back with a file size (which is really ignored - it
> would be zero if no file existed) and a return code that indicates if
> the file already exists or not. That gives us the chance to ask the
> user if they want to overwrite or not, if necessary. If the user wants
> to overwrite, or if there is no file to overwrite, then the put proceeds
> apace.
> > SO I am wondering if that could be backwards, what else might be?
> No one ever promised it was right... ;-)
