[linux-cifs-client] Re: [PATCH] CIFS: convert all delimiters in prefix path to match unix extensions

[Steve French]

Accepting either //server/share or \\server\share is fine with me -
beyond that all is left alone in userspace (although I don't mind
allowing the slash before the dir name to be either way if you think
that that would help \\server\share\<dir>  )

On Mon, Feb 25, 2008 at 6:37 AM, Jeff Layton <jlayton at redhat.com> wrote:
>
> On Fri, 15 Feb 2008 15:08:03 -0500
>  Jeff Layton <jlayton at redhat.com> wrote:
>
>  > On Fri, 15 Feb 2008 13:08:20 -0600
>  > "Steve French" <smfrench at gmail.com> wrote:
>  >
>  > > I don't think it is worth the trouble or memory to store the path
>  > > twice although I don't mind handling the easy case in which we
>  > > reconnect to Windows after being Samba, and log an error and/or refuse
>  > > reconnect if we switch the other way on reconnect and there is a long
>  > > prefixpath.
>  > >
>  > > Your patch was not quite right since posix path support are an
>  > > optional capability even if Unix Extensions are on.  This fixes the
>  > > flag check and also adds a reconnect warning error for the case we
>  > > discussed.   Thoughts?
>  > >
>  > > http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=11b6d6450c10066e83e19f6ff57d55678c3e9f13
>  > >
>  >
>  > Good catch. The patch looks good to me.
>  >
>  > I'll start work on a respun mount.cifs patch in the near future, and
>  > I'll also see about adding a section about delimiters to the mount.cifs
>  > manpage too.
>  >
>
>  Ok, I've gotten a few things off of my plate and am going to start
>  working on respinning the userspace patch soon. That means that we need
>  to decide on what sort of behavior we want mount.cifs to implement for
>  converting delimiters.
>
>  We know that we want mount.cifs to send paths with '/' exclusively as a
>  delimiter so that we can allow for embedded '\' in the path. As I see
>  it, we have 3 possible approaches:
>
>  1) autoconvert '\' to '/', but only where possible. This means the
>  first 2 characters before the server piece and the character following
>  it (presuming of course that '\' is never a valid character in a
>  hostname or address). Everything else we would assume is set up
>  correctly already.
>
>  2) autoconvert '\' to '/' everywhere, but allow for some mechanism to
>  escape embedded '\' characters (maybe convert double backslashes to
>  embedded singles).
>
>  3) assume that the path is already using '/' as a delimiter, and don't
>  try to convert anything. If we get a path with a backslash where we
>  expect a slash, throw an error back to the user saying that we require
>  '/' as a delimiter and anything else is invalid.
>
>  Personally, I think #3 would be the most clear for users. The downside
>  is that it might break some existing setups that are currently
>  functioning. #1 seems like it would be confusing to users and #2 seems
>  like overkill to me.
>
>  I'm open to any of the three, however (or even another option if
>  someone wants to suggest something). Regardless of which option we
>  pick, I think a paragraph in the mount.cifs manpage clarifying
>  delimiter usage is needed.
>
>  Thoughts?
>
>
>
>  --
>  Jeff Layton <jlayton at redhat.com>
>



-- 
Thanks,

Steve