Sorry,
Trying again with corrected subject line...
> Date: Wed, 04 Mar 2009 11:44:06 -0800
> From: Joyce McIntosh <Joyce.McIntosh at sun.com>
>
> 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.
If I read the spec correctly this would never happen. 0x00f8 is a
Latin small letter o with stroke; not a '/' (AKA solidus or virgule)
character. Whether or not catia=true, an o with stroke character
will not be translated to '/'.
> > >
> > > (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).
The fact that you allow the translation of '/' in a filename implies
that files can exist containing that character. Therefore, you
appear to be assuming that I can have a directory 'a', a file in 'a'
named 'b' (which should be accessible by the pathname "a/b" and at
the same time have a file named "a/b" in the same directory. If I
then try to open "a/b", which file do I get?
> > >
> > > (c) create a bogus file on the system with '/' right in the
> > > directory entry, and no hope of ever removing with normal UNIX
> > > interfaces,
Same problem as (b) above. But it is even worse. Translation is
only done on readdir operations; not during pathname resolution.
So any filename that has been translated will not be removable
because the name you have been given as a result of the translation
is not the actual name of the file. (I.e., if I have a file named
'?', when I do the equivalent of an ls, the file name reported will
be an inverted question mark instead of normal question mark. If I
try to remove a file named '?', the unlink will fail because there
is no file with that name. (Or it might remove a different file
that actually is named '?' leaving the file named '?' untouched.)
> > >
> > > (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
Hi Joyce,
I apologize for the delay. Getting access to the case file was a
problem this morning and I was tied up all afternoon.
Note the comments I have in-line above. They boil down to two
points:
1. Will an application attempt to pass a pathname containing a
'/' character ever be translated by the system into a Latin
small letter o with stroke, or does this translation only
occur when reading filenames from a CIFS server?
From what you say above, I believe you are saying that the
only translation is on characters found in the names of
files that exist on a CIFS server. So, this will never happen.
So far, so good.
2. If I have four files with names "<>", "?>", "??", and "<?" on
a directory on a CIFS server with catia=true, it seems that
CATIA applications reading that directory will see four
different files with filename "??". If I have understood
this correctly, it seems to be a problem because all four of
these filenames are valid (although not portable) filenames on
some file systems.
The fact that readdir will give you one name while open, stat,
unlink, rename, etc. may need to use a different name seems like
a disaster waiting to happen.
- Don
