When converting trailing spaces and periods in paths, do so for every component of the path, not just the last component. If the conversion is not done for every path component, then subsequent operations in directories with trailing spaces or periods (e.g. create(), mkdir()) will fail with ENOENT. This is because on the server, the directory will have a special symbol in its name, and the client needs to provide the same.
Cc: stable@vger.kernel.org # 4.9.x-5.8.x Signed-off-by: Boris Protopopov pboris@amazon.com --- fs/cifs/cifs_unicode.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c index 498777d859eb..9bd03a231032 100644 --- a/fs/cifs/cifs_unicode.c +++ b/fs/cifs/cifs_unicode.c @@ -488,7 +488,13 @@ cifsConvertToUTF16(__le16 *target, const char *source, int srclen, else if (map_chars == SFM_MAP_UNI_RSVD) { bool end_of_string;
- if (i == srclen - 1) + /** + * Remap spaces and periods found at the end of every + * component of the path. The special cases of '.' and + * '..' do not need to be dealt with explicitly because + * they are addressed in namei.c:link_path_walk(). + **/ + if ((i == srclen - 1) || (source[i+1] == '\')) end_of_string = true; else end_of_string = false;
On Sat, Oct 17, 2020 at 03:28:39PM +0000, Boris Protopopov wrote:
When converting trailing spaces and periods in paths, do so for every component of the path, not just the last component. If the conversion is not done for every path component, then subsequent operations in directories with trailing spaces or periods (e.g. create(), mkdir()) will fail with ENOENT. This is because on the server, the directory will have a special symbol in its name, and the client needs to provide the same.
Cc: stable@vger.kernel.org # 4.9.x-5.8.x Signed-off-by: Boris Protopopov pboris@amazon.com
fs/cifs/cifs_unicode.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c index 498777d859eb..9bd03a231032 100644 --- a/fs/cifs/cifs_unicode.c +++ b/fs/cifs/cifs_unicode.c @@ -488,7 +488,13 @@ cifsConvertToUTF16(__le16 *target, const char *source, int srclen, else if (map_chars == SFM_MAP_UNI_RSVD) { bool end_of_string;
if (i == srclen - 1)
/*** Remap spaces and periods found at the end of every* component of the path. The special cases of '.' and* '..' do not need to be dealt with explicitly because* they are addressed in namei.c:link_path_walk().**/if ((i == srclen - 1) || (source[i+1] == '\\')) end_of_string = true; else end_of_string = false;-- 2.18.4
What is the git commit id of this in Linus's tree?
thanks,
greg k-h
I could not find the patch in Linus's tree at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/c... or in the commit list. The patch is in linux-next, commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?...
On 10/18/20, 1:56 AM, "Greg KH" gregkh@linuxfoundation.org wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Sat, Oct 17, 2020 at 03:28:39PM +0000, Boris Protopopov wrote: > When converting trailing spaces and periods in paths, do so > for every component of the path, not just the last component. > If the conversion is not done for every path component, then > subsequent operations in directories with trailing spaces or > periods (e.g. create(), mkdir()) will fail with ENOENT. This > is because on the server, the directory will have a special > symbol in its name, and the client needs to provide the same. > > Cc: stable@vger.kernel.org # 4.9.x-5.8.x > Signed-off-by: Boris Protopopov pboris@amazon.com > --- > fs/cifs/cifs_unicode.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c > index 498777d859eb..9bd03a231032 100644 > --- a/fs/cifs/cifs_unicode.c > +++ b/fs/cifs/cifs_unicode.c > @@ -488,7 +488,13 @@ cifsConvertToUTF16(__le16 *target, const char *source, int srclen, > else if (map_chars == SFM_MAP_UNI_RSVD) { > bool end_of_string; > > - if (i == srclen - 1) > + /** > + * Remap spaces and periods found at the end of every > + * component of the path. The special cases of '.' and > + * '..' do not need to be dealt with explicitly because > + * they are addressed in namei.c:link_path_walk(). > + **/ > + if ((i == srclen - 1) || (source[i+1] == '\')) > end_of_string = true; > else > end_of_string = false; > -- > 2.18.4 >
What is the git commit id of this in Linus's tree?
thanks,
greg k-h
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
A: No. Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Oct 19, 2020 at 02:17:35PM +0000, Protopopov, Boris wrote:
I could not find the patch in Linus's tree at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/c... or in the commit list. The patch is in linux-next, commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?...
Have you read the rules for stable patches: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Please do so, you seem to be missing the "MUST BE IN LINUS'S TREE" requirement...
greg k-h
OK thanks I will resubmit later.
On 10/19/20, 1:42 PM, "Greg KH" gregkh@linuxfoundation.org wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
A: No. Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Oct 19, 2020 at 02:17:35PM +0000, Protopopov, Boris wrote: > I could not find the patch in Linus's tree at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/c... or in the commit list. The patch is in linux-next, commit https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?...
Have you read the rules for stable patches: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Please do so, you seem to be missing the "MUST BE IN LINUS'S TREE" requirement...
greg k-h
linux-stable-mirror@lists.linaro.org
-
Boris Protopopov -
Greg KH -
Protopopov, Boris