libsmbclient url encoding is one-way but two-way is needed

[Derrell.Lipman at UnwiredUniverse.com]

When a URL is passed to libsmbclient, it is "decoded"; i.e. %xx is converted
to the character thereby represented.  This is all well and good.

When an opendir/readir sequence is done, file names, possibly containing the
'%' character, are returned to the user *unencoded*.  This means that if you
have a path name which you opendir(), read a file name using readdir(), append
the file name to the path name, and attempt to smbc_open(), smbc_stat(),
etc. the file, it will fail because the file name _actually_ contains a
percent sign (really a full percent sign encoding), but the percent sign and
following characters are being (undesirably, in this case) decoded by
smbc_open() or smbc_stat().  This can occur under very normal circumstances
when, as one of many examples I found, you read the Temporary Internet Files
folder which contains encoded urls as file names.

It seems to me that if we're passing url strings _to_ the libsmbclient
functions, we should provide url strings as return values from them (or at
least provide an option to do so).  Returning encoded strings would be
undesirable if you wanted to display the names to a user who couldn't care
less about how the internal encoding is done, but highly desirable when the
name will be passed back to the client library.

What's your take on it?  Provide an option to have returned folder/file names
urlencoded?  Provide a function in the library which may be called with a
string (the returned folder/file name), to urlencode it?  Or just leave it
entirely up to each user of the library to implement his own encoding
function?

Derrell