James Carlson wrote: > 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. > > Your guess is correct. The answer is (a). The file system would not allow us to create the file (due to the '/' character) and thus the request would fail.
Joyce
