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... ;-)