25 Jun, 2016

1 commit


17 Oct, 2014

2 commits

  • This is a bigger patch, but its size is mostly due to
    a single change for how we check for remapping illegal characters
    in file names - a lot of repeated, small changes to
    the way callers request converting file names.

    The final patch in the series does the following:

    1) changes default behavior for cifs to be more intuitive.
    Currently we do not map by default to seven reserved characters,
    ie those valid in POSIX but not in NTFS/CIFS/SMB3/Windows,
    unless a mount option (mapchars) is specified. Change this
    to by default always map and map using the SFM maping
    (like the Mac uses) unless the server negotiates the CIFS Unix
    Extensions (like Samba does when mounting with the cifs protocol)
    when the remapping of the characters is unnecessary. This should
    help SMB3 mounts in particular since Samba will likely be
    able to implement this mapping with its new "vfs_fruit" module
    as it will be doing for the Mac.
    2) if the user specifies the existing "mapchars" mount option then
    use the "SFU" (Microsoft Services for Unix, SUA) style mapping of
    the seven characters instead.
    3) if the user specifies "nomapposix" then disable SFM/MAC style mapping
    (so no character remapping would be used unless the user specifies
    "mapchars" on mount as well, as above).
    4) change all the places in the code that check for the superblock
    flag on the mount which is set by mapchars and passed in on all
    path based operation and change it to use a small function call
    instead to set the mapping type properly (and check for the
    mapping type in the cifs unicode functions)

    Signed-off-by: Steve French

    Steve French
     
  • This allows directory listings to Mac to display filenames
    correctly which have been created with illegal (to Windows)
    characters in their filename. It does not allow
    converting the other direction yet ie opening files with
    these characters (followon patch).

    There are seven reserved characters that need to be remapped when
    mounting to Windows, Mac (or any server without Unix Extensions) which
    are valid in POSIX but not in the other OS.

    : \ < > ? * |

    We used the normal UCS-2 remap range for this in order to convert this
    to/from UTF8 as did Windows Services for Unix (basically add 0xF000 to
    any of the 7 reserved characters), at least when the "mapchars" mount
    option was specified.

    Mac used a very slightly different "Services for Mac" remap range
    0xF021 through 0xF027. The attached patch allows cifs.ko (the kernel
    client) to read directories on macs containing files with these
    characters and display their names properly. In theory this even
    might be useful on mounts to Samba when the vfs_catia or new
    "vfs_fruit" module is loaded.

    Currently the 7 reserved characters look very strange in directory
    listings from cifs.ko to Mac server. This patch allows these file
    name characters to be read (requires specifying mapchars on mount).

    Two additional changes are needed:
    1) Make it more automatic: a way of detecting enough info so that
    we know to try to always remap these characters or not. Various
    have suggested that the SFM approach be made the default when
    the server does not support POSIX Unix extensions (cifs mounts
    to Samba for example) so need to make SFM remapping the default
    unless mapchars (SFU style mapping) specified on mount or no
    mapping explicitly requested or no mapping needed (cifs mounts to Samba).

    2) Adding a patch to map the characters the other direction
    (ie UTF-8 to UCS-2 on open). This patch does it for translating
    readdir entries (ie UCS-2 to UTF-8)

    Signed-off-by: Steve French
    Reviewed-by: Shirish Pargaonkar

    Steve French
     

09 Sep, 2013

1 commit

  • The existing NLS case conversion routines do not appropriately handle
    the (now common) case where the local host is using UTF8. This is
    because nls_utf8 has no support at all for converting a utf8 string
    between cases and the NLS infrastructure in general cannot handle
    a multibyte input character.

    In any case, what we really need for cifs is to emulate how we expect
    the server to convert the character to upper or lowercase. Thus, even
    if we had routines that could handle utf8 case conversion, we likely
    would end up with the wrong result if the name ends up being in the
    upper planes.

    This patch adds a new scheme for doing unicode case conversion. The
    case conversion tables that Microsoft has published for Windows 8
    have been converted to a set of lookup tables, and a routine is
    added to convert a wchar_t from lower to uppercase using those
    tables.

    Reported-and-Tested-by: Jan-Marek Glogowski
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

27 Jun, 2013

1 commit

  • This is RH bug 970891
    Uppercasing of username during calculation of ntlmv2 hash fails
    because UniStrupr function does not handle big endian wchars.

    Also fix a comment in the same code to reflect its correct usage.

    [To make it easier for stable (rather than require 2nd patch) fixed
    this patch of Shirish's to remove endian warning generated
    by sparse -- steve f.]

    Reported-by: steve
    Signed-off-by: Shirish Pargaonkar
    Cc:
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Steve French
     

25 Jul, 2012

2 commits


19 Jan, 2012

1 commit


19 May, 2011

1 commit

  • Move extern for cifsConvertToUCS to different header to prevent following warning:

    CHECK fs/cifs/cifs_unicode.c
    fs/cifs/cifs_unicode.c:267:1: warning: symbol 'cifsConvertToUCS' was not declared. Should it be static?

    Signed-off-by: Steve French
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Steve French
     

12 Apr, 2011

1 commit

  • Minor revision to the original patch. Don't abuse the __le16 variable
    on the stack by casting it to wchar_t and handing it off to char2uni.
    Declare an actual wchar_t on the stack instead. This fixes a valid
    sparse warning.

    Fix the spelling of UNI_ASTERISK. Eliminate the unneeded len_remaining
    variable in cifsConvertToUCS.

    Also, as David Howells points out. We were better off making
    cifsConvertToUCS *not* use put_unaligned_le16 since it means that we
    can't optimize the mapped characters at compile time. Switch them
    instead to use cpu_to_le16, and simply use put_unaligned to set them
    in the string.

    Reported-and-acked-by: David Howells
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

20 Aug, 2010

1 commit


02 May, 2009

1 commit


01 May, 2009

1 commit

  • In most cases, cifs_strndup is converting from Unicode (UCS2 / UTF-32) to
    the configured local code page for the Linux mount (usually UTF8), so
    Jeff suggested that to make it more clear that cifs_strndup is doing
    a conversion not just memory allocation and copy, rename the function
    to including "from_ucs" (ie Unicode)

    Signed-off-by: Steve French

    Steve French
     

30 Apr, 2009

4 commits


08 Feb, 2008

1 commit


13 Jul, 2007

1 commit

  • This should be the last big batch of whitespace/formatting fixes.
    checkpatch warnings for the cifs directory are down about 90% and
    many of the remaining ones are harder to remove or make the code
    harder to read.

    Signed-off-by: Steve French

    Steve French
     

29 Jun, 2007

1 commit


12 Nov, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds