[linux-cifs-client] RE: Longnames (was problems with cifs)

[Naidu Bollineni]

I got the "mapchars" change into my tree, and seems to be OK. I could
create a file with '<', and '>' in filename, and display it after fixing
the following bug.

I see a missing break statement in cifs_convertUCSpath() routine for the
case of "<" character - this being the last case in switch(). After
putting it, I am getting correct behaviour, otherwise I see '?' in place
of '<' in the pathname.

So, if the files were created win a share without 0xF000 ORed into each
widechar of name, the files still get mangled into 8.3 format, right?

Is there still a way to get the true names? Is it possible at all? 

Naidu Bollineni
Senior Member Technical Staff
Kazeon Systems
naidu at kazeon.com
www.kazeon.com

> -----Original Message-----
> From: Jeremy Allison [mailto:jra at samba.org]
> Sent: Friday, May 06, 2005 12:22 AM
> To: Steve French
> Cc: Naidu Bollineni; linux-cifs-client at lists.samba.org
> Subject: Re: [linux-cifs-client] RE: Longnames (was problems with
cifs)
> 
> On Thu, May 05, 2005 at 07:11:51PM -0500, Steve French wrote:
> > On Thu, 2005-05-05 at 13:12, Naidu Bollineni wrote:
> > > The filenames do have <, > characters in them.
> > > With mapping the illegal characters (by ORing 0xFF00 to the
> character),
> > > is it possible for server to return the true name at all, if the
> client
> > > says it can handle such things?
> >
> > Yes. If the "mapchars" mount option is used, the reserved characters
> > (except slash) will be mapped going to/from the server, allowing you
to
> > create files with such characters in the filename and see them in
ls,
> > stat etc.
> 
> Ok, based on feedback gathered over here at SambaXP I'm
> going to fix the parsing algorithms for 3.0.XX (where XX > 14a)
> so that "mapchars" isn't needed - we'll allow the "illegal" characters
> from a CIFSFS client.
> 
> Jeremy.