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

[Steve French]

 > The actual path is this:
 >  \.camel_certs\ba:aa:aa:aa:aa:aa    etc.

Arrgggghhh.    ':'  is an invalid character in a cifs filename.  With 
one excpetion - presumably it could indicate a data stream (which Samba 
3 would not support in any case) - in which case file file /.camel/ba 
would need to exist for the stream name after the : to make sense    :)

Presumably this is not some cross platform app that has some friendly 
configure option to work around illegal characters in file names right ...

Anyone know what this looks like (ie creating a filename with a :  in it 
on Windows) when a Windows system has the Windows SFU (Service for Unix) 
installed which IIRC is a free download?  Perhaps they use the POSIX 
flag in the Open request to bypass the name check??  Would be easy 
enough to see what flows on the wire - and what it looks like on t2 
FindFirst when you see a locally created weird filename in a directory

jra,
Any chance you can turn off the checking for valid Unix, invalid Windows 
characters, for cases when Unix extensions are negotiated are for POSIX 
flag or client?

By the way this does show a bug in Samba 3  e.g.

    echo "some data" > /mnt/1a:aa
fails to Samba 3 with (a not a directory error - which can't be right), 
while it succeeds to Windows (which implicitly creates the file 1a, and 
presumably the associated "stream" aa     Presumably since Samba 3 does 
not support streams that is part of the problem - but the file (zero 
length) is implicitly created as a side effect (perhaps someone could 
try this experiment to a Windows FAT partition and see what error 
Windows returns, if any,when you try to create the file remotely with a :  

My guess is that if we fix Samba to match Windows behavior that would 
get past a few of the app problems - although not solve the problem of 
how to deal with readdir not listing the file in the directory listing.  
Note that both lookup and stat from my client to Windows (for the file 
"1a:aa") work and return expected results as if it were a distinct file 
(that is how streams are expected work so I should not have been 
surprised).   I hate to wait for Samaba4 to fix this with streams when 
really this should not be a streams issue.