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

Jeff Layton jlayton at redhat.com
Mon Feb 25 12:37:12 GMT 2008


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>


More information about the linux-cifs-client mailing list