diff options
| -rw-r--r-- | source3/smbd/reply.c | 32 |
1 files changed, 30 insertions, 2 deletions
diff --git a/source3/smbd/reply.c b/source3/smbd/reply.c index 210b7010d9..6e1cd27803 100644 --- a/source3/smbd/reply.c +++ b/source3/smbd/reply.c @@ -3849,6 +3849,26 @@ nosendfile_read: } /**************************************************************************** + MacOSX clients send large reads without telling us they are going to do that. + Bug #9572 - File corruption during SMB1 read by Mac OSX 10.8.2 clients + Allow this if we are talking to a Samba client, or if we told the client + we supported this. +****************************************************************************/ + +static bool server_will_accept_large_read(void) +{ + /* Samba client ? No problem. */ + if (get_remote_arch() == RA_SAMBA) { + return true; + } + /* Need UNIX extensions. */ + if (!lp_unix_extensions()) { + return false; + } + return true; +} + +/**************************************************************************** Reply to a read and X. ****************************************************************************/ @@ -3858,6 +3878,7 @@ void reply_read_and_X(struct smb_request *req) files_struct *fsp; off_t startpos; size_t smb_maxcnt; + size_t upper_size; bool big_readX = False; #if 0 size_t smb_mincnt = SVAL(req->vwv+6, 0); @@ -3892,8 +3913,15 @@ void reply_read_and_X(struct smb_request *req) return; } - if (global_client_caps & CAP_LARGE_READX) { - size_t upper_size = SVAL(req->vwv+7, 0); + upper_size = SVAL(req->vwv+7, 0); + if ((upper_size != 0) && server_will_accept_large_read()) { + /* + * This is Samba only behavior (up to Samba 3.6)! + * + * Windows 2008 R2 ignores the upper_size, + * so we do unless unix extentions are active + * or "smbclient" is talking to us. + */ smb_maxcnt |= (upper_size<<16); if (upper_size > 1) { /* Can't do this on a chained packet. */ |