SMBC_parse_path doesn't seem to handle special characters

Eduardo Kienetz eduardo at
Mon Jan 25 09:52:32 MST 2010

On Sun, Jan 24, 2010 at 5:16 AM, Volker Lendecke
<Volker.Lendecke at>wrote:

> On Sun, Jan 24, 2010 at 12:32:25AM -0600, Eduardo Kienetz wrote:
> > Agreed, but the bottom line is that that's supported, because some
> developer
> > had [good?] reasons to do so, and it doesn't work right :)
> True. But then to cover that 100% we need a proper escaping
> mechanism, something like quoted-printable or base64-encoded
> utf8 (like LDAP does) that fits into the url scheme.

Oh, you mean we should require the password to be base64 encoded? Doesn't
seem that good since it still might return / in it (unless we use modified

I think what would solve our problem once and for all is to require escaping
the @s that are part of the password. That would also eliminate the need for
my first patch.
e.g.: smb://user:p\@ss/word\\@m@serv@r/m@share/m@filename.txt
In this case we'd have:
1) password (the backslah right before the @ was for escaping): p at ss/word\@m
2) server: serv at r
3) share: m at share

This way we'd look for the first : (indicating a password separator,
usernames can't contain :), then just look for the next unescaped @ (server

The reason I'm a bit reluctant to put in your patch directly
> is the fact that I personally are always scared by
> string-parsing. This code is already very hard to
> understand for me.

Well, it's quite simple though, but it'll not be needed once I use the
escaping idea from above :)
Hold on tight.

> > P.S.: it looks like I'll have to create a
> > "get_last_token_no_ltrim_talloc()", so that I can use at libsmb_path.c
> > instead of next_token_no_ltrim_talloc(ctx, &p, &userinfo, "@"). That's to
> > support parsing URLs with passwords containing @ (clarifying what I said
> in
> > my first e-mail).
> Hehe, that kindof supports my statement "string parsing is
> scary", doesn't it? :-)

Indeed, but I realized it wouldn't really help since server name, share name
and file/folder can contain @.
I'm glad I realized backslashing the @s in the password would be enough to
solve everything, if I didn't miss anything, as it seems to me :)

Hold on, will submit it asap.

Eduardo Bacchi Kienetz

More information about the samba-technical mailing list