From: Steve French <smfrench@austin.rr.com>
To: torvalds@osdl.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] [CIFS] Two small cifs patches
Date: Sun, 14 Aug 2005 16:55:23 -0500 [thread overview]
Message-ID: <42FFBDCB.2040804@austin.rr.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 168 bytes --]
Based on testing at the cifs plugfest last week these were the two most
important patches from among those pending in my tree. The rest can
wait until after 2.6.12
[-- Attachment #2: CIFS-Fix-missing-entries-in-search-results-when-very-long-file-names-and.patch --]
[-- Type: text/x-patch, Size: 955 bytes --]
[PATCH] [CIFS] Fix missing entries in search results when very long file names and
more than 50 (or so) of such long search entries in the directory. FindNext
could send corrupt last byte of resume name when resume key was a few hundred
bytes long file name or longer.
Fixes Samba Bug # 2932
Signed-off-by: Steve French (sfrench@us.ibm.com)
---
fs/cifs/cifssmb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
ef6724e32142c2d9ca252d423cacc435c142734e
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -2628,6 +2628,9 @@ int CIFSFindNext(const int xid, struct c
if(name_len < PATH_MAX) {
memcpy(pSMB->ResumeFileName, psrch_inf->presume_name, name_len);
byte_count += name_len;
+ /* 14 byte parm len above enough for 2 byte null terminator */
+ pSMB->ResumeFileName[name_len] = 0;
+ pSMB->ResumeFileName[name_len+1] = 0;
} else {
rc = -EINVAL;
goto FNext2_err_exit;
[-- Attachment #3: CIFS-Fix-path-name-conversion-for-long-filenames-when-mapchars-mount.patch --]
[-- Type: text/x-patch, Size: 1003 bytes --]
[PATCH] [CIFS] Fix path name conversion for long filenames when mapchars mount
option was specified at mount time.
Signed-off-by: Steve French (sfrench@us.ibm.com)
---
fs/cifs/CHANGES | 6 ++++++
fs/cifs/misc.c | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
f4cfd69cf349dd27e00d5cf804b57aee04e059c2
diff --git a/fs/cifs/CHANGES b/fs/cifs/CHANGES
--- a/fs/cifs/CHANGES
+++ b/fs/cifs/CHANGES
@@ -1,3 +1,9 @@
+Version 1.35
+------------
+Add writepage performance improvements. Fix path name conversions
+for long filenames on mounts which were done with "mapchars" mount option
+specified.
+
Version 1.34
------------
Fix error mapping of the TOO_MANY_LINKS (hardlinks) case.
diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -611,6 +611,7 @@ cifsConvertToUCS(__le16 * target, const
src_char = source[i];
switch (src_char) {
case 0:
+ target[j] = 0;
goto ctoUCS_out;
case ':':
target[j] = cpu_to_le16(UNI_COLON);
reply other threads:[~2005-08-14 21:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42FFBDCB.2040804@austin.rr.com \
--to=smfrench@austin.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox