alpha_strcpy() problem

[John E. Malmberg]

On Wed, 15 Aug 2001, Andrew Tridgell wrote:

> > The 2nd (or 3rd) byte of multibyte character often becomes non-ASCII
> > code, so we cannot use multibyte NetBIOS name correctly now in HEAD
> > branch.
> > Is there any reason not to use characters except '/'?
> 
> yes, other characters are potentially dangerous, eg:
> 
>   "foo\"; rm -rf ."
> 
> or %, for example if someone used %H in a netbios name, samba would
> later replace it with a home directory.

Is there some way to flag these characters or names when converting from
the wire to internal that they are actually characters, and not to be
substituted when passed to a routine that does the macro substitution?
 
> It may be that we can safely allow for any non-7bit chars. The risk
> then is if the filesystem on the machine strips off the 8th bit and
> that produces a "/". Nasty.
> 
> I'm not sure what the best way to handle this is. Suggestions?

There is also the problem where there is more than one way to specify
a non-ASCII character in a filename to the filesystem.  If it comes over
the wire in a different format than the filesystem returns it in, it
could fail in several areas of SAMBA, or applications that are accessing
files through SAMBA.

And not all valid UNIX filespecifications can be served to Windows even
using ASCII.  For example the file "foo\bar\report.txt" can not be used on
a Microsoft client to a SAMBA server.


OpenVMS currently has two file systems of concern to SAMBA, one is not
case sensitive, and has several limitations.  It is the traditional one
and so is the most common.  All characters that do not map to legal
characters are replaced with an "escape" sequence of a flag and the hex
representation of the character.  That translation is handled
transparently to SAMBA but incurs a bit of overhead.

For the first filesystem, the "wrapper" layer makes sure that 8 bit
characters are handled properly.


The second filesystem will handle most UNIX and Microsoft and UNICODE file
names.  But problems still remain, as it allows several ways to specify
some characters.  This means that the filenames must still be examined to
make sure that they are represented in a consistent way.  It is an area
that still needs more work for OpenVMS "wrapper" layer.


It seems that like the 8.3 names mangling, there is no solution that will
either serve all valid UNIX filenames, or allow 100% of reversable
handling of characters that the host file system can not deal with.

It may be feasable to provide a substitution table like a codepage that
allows a user to substitute a common character for them on Microsoft
windows for one that they do not really need.

-John
wb8tyw at qsl.network
Personal Opinion Only