08-12-2009 07:07 PM
When doing an OBEX pull, I'm having the following problems:
- The sender is not properly setting the HeaderSet.Length header. This means that getting this value or using Operation.getLength will both fail
- I'm reading a close-format binary stream where I cannot get the length from the begining of the file
Reading until EOF exception does work -- however:
- I'm getting premature EOF's -- calling all forms of read() on the op.get(Data)InputStream will result in spurious -1's (EOF's) being return.
Continuing to read past these values will return more valid data.- Reading until the (caught and handled) EOF exception, while the resultant data is valid, causes an immediate failure of the transfer, causing the file to stay on the source device. This failure happens at the time of the read, even before the onPut handler returns
OBEX_HTTP_OK. This means that that the JSR82 API is aborting the join of my handler, detaching and returning an error, even before my handler completes. (I can also tell be setting up remote debugging and breakpointing on the EOF exception-handler - the xfer has already failed by this point, as reported by the sending device.)
- As a test, I can try a send, fail but mark the file size, then send again using the cached size and it does work. (I have to send everything twice.)
- Note that for payloads less than 4039 bytes, things seems to work ok if I read .available() bytes. (This is the value that the DataInputStream .available() will max out at - probably a internal BT/DAS buffer size.) I know that .available() only returns what is avaialble w/o blocking, but again, if I read up to EOF, then the xfer fails.
- .available() is not supported on the plain inputStream, and reading past EOF (skipping the spurious EOF's) has the same problem.
The following links show others seeing similar behavior on other platforms - at least the premature EOF issue (but not the failure past EOF issue):
thanks for any help