We just upgraded smbclient from 3.0.4 to 3.0.22 (maybe add a new verision in bugzilla). And i quickly stumbled upon an quite evil error. It seems smbclient fails to read the last chunk of a file when CAP_LARGE_READX is set agains some servers.
I've tested this against a Windows XP-SP2 share. I've tracked down the issue to cli_read in clireadwrite.c.
When CAP_LARGE_READX is set, reads default to a 17bit's size'd request. Ie it set's the first bit of byte 51 to 1 to read the full 127kb data. However in the response from the server, this bit is not set. So seems server only responds with 64k chunks.
This happens on each read request, but no error is triggered. cliread bails due to that it got less than requested. and returns a smaller value than requested.
This seem to not be a problem while file has more than the CLI_MAX_LARGE_READX_SIZE data left. But when end of file is hit, no data get's returned from cliread. I'm not sure why, but i suppose it might be that server has closed file due to smbclient having actually requested data passed eof.
I'm not sure if the returned data actually has all requested data, and it's just the bit that isn't set or if server just doesn't support 127k reads and reverts back to 64k. The former would be more logical due to that is stops returning data on last request.
For now we've just reverted back to not using large requests, with the added performance penalty.
Can anybody shed some light into this. Our client is a ported variant of libsmbclient running on xbox, but not changes have been made in regards to this i would think.
I'm not sure this is relevant, but according to this comment. max read should be 64k when CAP_LARGE_READX is set..
That would explain why things behave weird.
This one is a show-stopper for final 3.0.23 (IMHO). Not for the pre-release though.
What size of file are you using ? Does this happen to any other server than Windows XP ? Have you tried against W2K or W2K3 ?
files was exactly 50 000 000 bytes. sadly i don't have any other windows servers in the network here. only a NAS drive that didn't set that flag.
maybe i can get some other developer to try it thou, will check with them.
Ok, I've duplicated the bug against W2K3 - latest SP. Windows has a bug with requesting *exactly* 64k reads with large read set. It returns zero bytes. I'll code around this.
ah, the leftover data was probably 64k then. maybe also change that loop so that it doesn't exit just because the response didn't give all data, not that it matter much, since it'll work anyway. but just for clearity that that doesn't mean eof.
cheers for looking into it.
Created attachment 1872 [details]
Should be working for 3.0.23. Please reopen if not.
just for sake of clearity so this bug doesn't crop up again.. the bug isn't really that requesting exactly 64k returns zero data.. the bug is that the 17th bit is ignored.. so in the case of a 64k read (wich only has the 17th bit set, all other 0), no data is returned. the current bug fix is still as reported before working just fine.
maybe make a comment about it in source thou.
just ran into this bug once again in 3.0.23b, this time against a lan drive instead of windows server. i suppose it doesn't report itself as a windows server but a samba server, thus the max readsize isn't reduced. once again, the leftover data is exactly 64k (64*1024). I didn't debug into samba code this time, but i'm sure it's the same issue.
just pondered this abit more.. it wouldn't be to hard to detect this behavior in that read function.
if 17th bit set in request
if returnedsize == (request & ~(1<<16))
bug detected, server ignores 17th bit
from now on, never use > 64k-1 reads
on this server
if returnedsize == 0
Is this still an issue in Samba 3.4.3?
no feedback and presumably fine in curent versions.