The Samba-Bugzilla – Attachment 7679 Details for
Bug 9017
file corrupted when copied from cifs mounted OS/2 share
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
patch -- when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize
0001-cifs-when-server-doesn-t-set-CAP_LARGE_READ_X-cap-de.patch (text/plain), 2.18 KB, created by
Jeff Layton
on 2012-06-30 11:37:16 UTC
(
hide
)
Description:
patch -- when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize
Filename:
MIME Type:
Creator:
Jeff Layton
Created:
2012-06-30 11:37:16 UTC
Size:
2.18 KB
patch
obsolete
>From 74f7777ccf593550f7417a582b742b5d1a92eb2d Mon Sep 17 00:00:00 2001 >From: Jeff Layton <jlayton@redhat.com> >Date: Sat, 30 Jun 2012 07:33:37 -0400 >Subject: [PATCH] cifs: when server doesn't set CAP_LARGE_READ_X, cap default > rsize at MaxBufferSize > >When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states >that you must cap the size of the read at the client's MaxBufferSize. >Unfortunately, testing with many older servers shows that they further >cap the size of a READ_ANDX response at the size of the server's >MaxBufferSize. > >Since we can't clearly tell what the server will do, we must be >conservative here for the default. When the server can't do large reads, >then assume that it can't satisfy any read larger than its MaxBufferSize >either. This just governs the default however. The admin can always >override this on his own. > >Cc: <stable@vger.kernel.org> # 3.2 >Reported-by: David H. Durgee <dhdurgee@acm.org> >Signed-off-by: Jeff Layton <jlayton@redhat.com> >--- > fs/cifs/connect.c | 9 +++------ > 1 files changed, 3 insertions(+), 6 deletions(-) > >diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c >index 402fe08..f0a1a24 100644 >--- a/fs/cifs/connect.c >+++ b/fs/cifs/connect.c >@@ -3508,18 +3508,15 @@ cifs_negotiate_rsize(struct cifs_tcon *tcon, struct smb_vol *pvolume_info) > * MS-CIFS indicates that servers are only limited by the client's > * bufsize for reads, testing against win98se shows that it throws > * INVALID_PARAMETER errors if you try to request too large a read. >+ * OS/2 just sends back short reads. > * >- * If the server advertises a MaxBufferSize of less than one page, >- * assume that it also can't satisfy reads larger than that either. >- * >- * FIXME: Is there a better heuristic for this? >+ * If the server doesn't advertise CAP_LARGE_READ_X, then assume that >+ * it can't handle a read request larger than its MaxBufferSize either. > */ > if (tcon->unix_ext && (unix_cap & CIFS_UNIX_LARGE_READ_CAP)) > defsize = CIFS_DEFAULT_IOSIZE; > else if (server->capabilities & CAP_LARGE_READ_X) > defsize = CIFS_DEFAULT_NON_POSIX_RSIZE; >- else if (server->maxBuf >= PAGE_CACHE_SIZE) >- defsize = CIFSMaxBufSize; > else > defsize = server->maxBuf - sizeof(READ_RSP); > >-- >1.7.7.6 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 9017
:
7677
|
7678
| 7679 |
7684