Bug 3668 - smbclient fails to read last chunk of file, when CAP_LARGE_READX is set
Summary: smbclient fails to read last chunk of file, when CAP_LARGE_READX is set
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: smbclient (show other bugs)
Version: 3.0.23b
Hardware: Other Other
: P3 regression
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-08 07:33 UTC by Joakim Plate
Modified: 2011-03-21 19:12 UTC (History)
0 users

See Also:


Attachments
patch (2.97 KB, patch)
2006-04-21 21:31 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joakim Plate 2006-04-08 07:33:27 UTC
Hi, 

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.

/Joakim
Comment 1 Joakim Plate 2006-04-08 08:31:26 UTC
I'm not sure this is relevant, but according to this comment. max read should be 64k when CAP_LARGE_READX is set..

http://archives.neohapsis.com/archives/microsoft/various/cifs/2002-q4/0009.html

That would explain why things behave weird.
Comment 2 Jeremy Allison 2006-04-21 11:10:08 UTC
This one is a show-stopper for final 3.0.23 (IMHO). Not for the pre-release though.
Jeremy.
Comment 3 Jeremy Allison 2006-04-21 19:19:16 UTC
What size of file are you using ? Does this happen to any other server than Windows XP ? Have you tried against W2K or W2K3 ?
Jeremy.
Comment 4 Joakim Plate 2006-04-21 19:37:45 UTC
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.
Comment 5 Jeremy Allison 2006-04-21 19:46:04 UTC
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.
Thanks.
Jeremy.
Comment 6 Joakim Plate 2006-04-21 20:32:37 UTC
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.
/Joakim
Comment 7 Jeremy Allison 2006-04-21 21:31:43 UTC
Created attachment 1872 [details]
patch
Comment 8 Jeremy Allison 2006-04-23 11:13:03 UTC
Should be working for 3.0.23. Please reopen if not.
Jeremy.
Comment 9 Joakim Plate 2006-04-24 09:09:13 UTC
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.
Comment 10 Joakim Plate 2006-08-30 20:45:55 UTC
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.
Comment 11 Joakim Plate 2006-08-30 21:51:40 UTC
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 
      goto retry
    end
  end
end
Comment 12 Karolin Seeger 2009-12-11 08:03:11 UTC
Is this still an issue in Samba 3.4.3?
Comment 13 Björn Jacke 2011-03-21 19:12:38 UTC
no feedback and presumably fine in curent versions.