@@ -484,10 +484,21 @@ cifsConvertToUTF16(__le16 *target, const char *source, int srclen,
/**
* 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().
+ * '..' are need to be handled because of symlinks.
+ * They are treated as non-end-of-string to avoid
+ * remapping and breaking symlinks pointing to . or ..
**/
- if ((i == srclen - 1) || (source[i+1] == '\\'))
+ if ((i == 0 || source[i-1] == '\\') &&
+ source[i] == '.' &&
+ (i == srclen-1 || source[i+1] == '\\'))
+ end_of_string = false; /* "." case */
+ else if (i >= 1 &&
+ (i == 1 || source[i-2] == '\\') &&
+ source[i-1] == '.' &&
+ source[i] == '.' &&
+ (i == srclen-1 || source[i+1] == '\\'))
+ end_of_string = false; /* ".." case */
+ else if ((i == srclen - 1) || (source[i+1] == '\\'))
end_of_string = true;
else
end_of_string = false;
Calling 'ln -s . symlink' or 'ln -s .. symlink' creates symlink pointing to some object name which ends with U+F029 unicode codepoint. This is because trailing dot in the object name is replaced by non-ASCII unicode codepoint. So Linux SMB client currently is not able to create native symlink pointing to current or parent directory on Windows SMB server which can be read by either on local Windows server or by any other SMB client which does not implement compatible-reverse character replacement. Fix this problem in cifsConvertToUTF16() function which is doing that character replacement. Function comment already says that it does not need to handle special cases '.' and '..', but after introduction of native symlinks in reparse point form, this handling is needed. Signed-off-by: Pali Rohár <pali@kernel.org> --- fs/smb/client/cifs_unicode.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)