2009/139 CIFS CATIA Translation Share Property
Don Cragun
dcragun at sonic.net
Thu Mar 5 17:02:38 PST 2009
James,
Please find comments in-line below...
- Don
James Carlson wrote:
> Don Cragun writes:
>> Sorry,
>> Trying again with corrected subject line...
>
> [corrected cc line as well]
>
>> > > > 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 '/'.
>
> Actually, this is exactly what happens.
>
> If Windows were to use the o-with-stroke character and "catia" were
> set on the file system, then the file name would be translated by the
> Solaris server to have '/' in it, and the call would then fail.
I didn't get that from reading the spec. It thought it talked about
translating CATIA version 4 (which runs only on UNIX systems) filenames
to CATIA version 5 (which run both on UNIX and Windows systems)
filenames. I don't remember anything about translating the other way
around. (Since the OpenSolaris ARC site is off-line for a day, I can't
verify it now.)
>
>> > > >
>> > > > (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.
>
> Not really. It implies that the specification allows for this
> specific translation. If the underlying OS doesn't support having
> that character, then the translation table entry is effectively moot.
>
> That's the case here. The translation is "allowed," but since we're
> UNIX, it doesn't actually work.
OK. Good.
>
>> 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,
>
> No. That's backwards. That never happens.
>
> The translation occurs between the Solaris (UNIX) system and the
> Windows server. If the file on the Solaris system were to have a '/'
> in it (an impossibility), then that character would be translated to
> o-with-stroke on the Windows system.
>
> Applications using '/' are completely unaffected.
>
>> 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.
>
> That's not quite the case. The Solaris system *IS* the CIFS server.
>
> This is Solaris-as-server, not Solaris-as-client.
>
>> 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 "«»".
>
> Possibly so. So what?
>
>> 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.
>
> No. Those directory entries will be seen *ONLY* on the Windows
> system.
>
> This is a translation that occurs only for Windows clients when using
> a Solaris server.
>
> It has no effect whatsoever on applications running on a Solaris
> system, nor on UNIX clients of a Solaris server, nor on Solaris when
> acting as a client to any other server (CIFS included).
>
OK. Solaris applications are unaffected.
The only issue is that software running on Windows may not be able
to access some files on a Solaris server and may accidentally end
up working with a different file. But, since the characters that
cause this problem shouldn't appear in filenames on a Windows
system, it shouldn't matter. I'm OK with that.
More information about the opensolaris-arc
mailing list