Hi Don, Let me try again to clarify this for you.
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. A subsequent request from the windows client (e.g. to open the file) would pass the filename containing the 0x00f8 character. If a client passed a filename containing the '/' character this '/' character would not be subject to CATIA translation. CATIA translation is only performed on files accessed via the CIFS protocol, and only if explicitly enabled (CATIA translation is disabled by default). Please let me know if this answers your concern. Thanks Joyce Alan M Wright wrote: > dcragun wrote: > > > Date: Thu, 26 Feb 2009 08:36:01 -0500 From: James Carlson > > > > > > Jordan Brown writes: > > > > > I am sponsoring the following for fast track approval. The timer > > > > > expires Wednesday 4 March 2009. > > > > > > You didn't specify a release binding or a stability level for the new > > > interfaces. > > > > > > I'll guess at "patch/micro" and "Committed," and give it a +1 > > > (including the likely not-so-interesting '/' translation). > > > > So what is supposed to happen if a process tries to access or create a > > file with a pathname containing a '/' character? When creating a file, > > when is a '/' a directory separator and when is it a character in a > > filename? > > That's up to to the local operating system and the local file system, > and has nothing to do with this fasttrack. For the purpose of this > fasttrack, how a name in the file system came to contain a / is not > relevant. > > For this fasttrack, if a file name returned by the local file system > contained a / it would be converted, as indicated by the translation > table to 0x00f8, before that name is propagated to a Windows client. > > The left column of the table represents the list of characters that > are illegal in Windows file names. There is no requirement that > these characters be legal on any file system. > > > If I have a file with filename "a/b" and a directory with filename "a" > > and a file in that directory with filename "b", which file does an > > open() of "a/b" open for me? If there is no directory "a", but there is > > a filename "a/b", will open() of "a/b" give me ENOENT because "a" isn't > > an existing directory. (Note that according to the standards, the > > command: > > printf "%s/%s" $(dirname a/b) $(basename a/b) > > is supposed to print "a/b", not "./a/b" (i.e., they work on strings, > not > > on pathnames.) > > Those questions don't seem relevant to this fasttrack. > > Alan >
