ndmpd handles wrongly EOM and EOF conditions
cmd - userland programs
Solaris NDMP implementation doesn't conform to NDMP spec in following areas:
- Upon encountering EOF on tape the tape position should remain on BOT (beginning-of-tape) side of the file mark. In our implementation the position remains at EOT (end-of-tape) side of the file mark (as reported by SCSI inquiry).
- If ndmpd attempts to read from a new tape (nothing has been recorded on it) it returns EIO error instead of preferred EOM error.
- Repeated attempts to read at EOM should return EOM error according to the spec. Our implementation returns EOM just the first time and following reads fail with EIO.
While fixing obvious violations of NDMP standard the fix simplifies the code and makes it more reliable:
- ndmpd's magic EOM marker recorded at the end of tape has been purged from code. It was highly unreliable because it was recorded only after encountering EOM and thus couldn't be used for EOT detection for partially full tapes. Moreover it caused problems for some DMA, because they falsely interpreted EOM as a valid file stored on tape.
- current tape record number and block number weren't calculated correctly in some cases