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.

Reply via email to