Joyce McIntosh writes:
> The translation of a '/' character would be performed if a filename read
> from
> the file system (eg returned from VOP_READDIR) contains the '/' character.
> The '/' would be translated, within smbsrv, to 0x00f8 before passing the
> filename
> to the windows client.
Of course, at least on UNIX, that'll never happen. No file ever has
that character.
> A subsequent request from the windows client (e.g. to open the file) would
> pass the filename containing the 0x00f8 character.
What happens if a Windows client creates a new file containing the
0x00f8 character? Does that:
(a) fail, because a file name on UNIX can't possibly have a '/' in
it, and no file system should accept it.
(b) create a subdirectory (or subdirectories) using the first part
of the name, and a file using the last (i.e., interpret the
resulting back-translation into '/' as a separator).
(c) create a bogus file on the system with '/' right in the
directory entry, and no hope of ever removing with normal UNIX
interfaces.
(d) create a new file with a '0xf8' in the middle of it (I assume
we're not talking about wide characters here).
(e) do something else entirely, possibly using wide characters (!).
I'm guessing it's (a), but I think Don might be concerned about (c) or
one of the others.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
