[linux-cifs-client] cifs mounted home directory problems

[Åge Strand]

On Fri, 2005-04-01 at 02:45, Steven French wrote:
> >Is there a workaround or fix for the ':' problem? It still seems to
> be a
> >problem, even in linux kernel 2.6.10 /Samba 3.0.10. ...or I might
> very
> >well have overlooked some inanely obvious setting that solves this 
> >
> 
> yes - I have a plan (barring objections - which are likely on such
> a contentious topic) ... see below
> 
> >The problem is Evolution, KDE and other apps that use filenames
> >with the colon character (':') in them.
> >
> >Doing a stat on one of these files tells me quite rightly that it is
> a
> >regular file and all looks well up to that point, but if I try to cat
> >one of these files I get an error message saying "Not a directory".
> 
> Wow ... interesting data I just found out. Windows maps at least three
> of the illegal characters
> already (at least when SFU is installed) - and they are already mapped
> by the time they are
> sent over the network and stored in NTFS. They map
> \ / : * ? " < > |
> 
> to the same character prefaced by F0 - so in Unicode the 16 bit
> representation of : is sent as:
> 0xF0 0x3A
> instead of
> 0x00 0x3A
> 
> This means that the old command processor still displays them as a ?
> (which is fine since
> the filename can not be displayed). So I think that this means that
> Samba should be converting 
> at least the three
> : * ? 
> (those are the only three I tested) to/from the same form + 0xF000
> 
> Kind of interesting that Samba already works for: stat (QPathInfo),
> delete and rmdir but not open,
> but doing the 0xF000 trick would work.
> 
> I need to add that logic into my client as well - but if it is not in
> Samba then the files I create with : will
> look odd when viewed from NFS.

That would be a bad thing. Easy to test though.

> Interestingly this seems much better than the HFS approach (to map
> colon to \) at least for Linux HFS and
> probably better than my xattr ideas. 

It certainly sounds less invasive than the other approaches discussed
earlier in the thread, and probably easier to implement as well. Whether
it will break stuff I'm probably not the right person to judge.

It's a bit strange that stat/delete/rmdir should work but not open.
Somehow the mapping must work fine in those cases...?

> Also interesting that Samba returns very odd names (and empty
> altnames) on FindFirst full directory info on existing
> files with such illegal names - looks like a bug in the server
> FindFirst code.

Hmm, maybe an indicator that all is not well with the samba
implementation of the ':' stuff. Is this a show stopper for implementing
the 0xF0 patch? Or is it non-critical?


Oggy