Subject: The role of case insensitivity in NFSv4

From: Neil Brown <[email-masked]>
Date: Tue, 27 Jun 2000 11:26:14 +1000 (EST)

Hi,

 The issue of case insensitivity on file names in NFSv4 came up (by a
 fairly circuitous route) in linux-kernel recently and that has
 started me thinking more deeply about it.

 A couple of people have mentioned how case insensitive comparisons
 are not terribly well defined, and how different existing fs
 implementations do it differently.
 Whether that it true or not, it led me to question the extent to
 which NFSv4 needs to know about case insensitivity, and how this
 knowledge should be encoded.

 Firstly, the issue is broader than just 'case'.  I also involves
 truncation of filenames which are longer than allowable.

 The situation where the client needs to know/use this sort of
 information about the server is when it is asked to "lookup" some
 filename, and it already has some filenames in it's cache.
 It needs to be able to answer the question
   "Is this file name TheSameAs that file name?"
 where "TheSameAs" is an equivalence relation defined by the servers
 filesystem. 
 The client needs to get an answer either "yes" or "don't know".
 If "yes", it uses cached info, if "don't know" it doesn't.

 The inverse question:
   "Is this file note not TheSameAs that file name?"
 does not, I think, need to be asked.  If we were allowing servers
 to delegate write access to directories, then we might need questions
 like that but as it is, we don't.

 It is important to note in the above that "TheSameAs" is a
 server-filesystem defined relationship.

 I believe that it is the role of NFSv4 to allow the server to
 communicate this relationship to the client, but I don't believe that
 it is the role of NFSv4 to define a (non-trivial) relationship and
 assert that servers may, or may not, support it.
 By defining a "case_insensitive" relationship as draft-07 does
 (talking about the words 'Capital' or 'small' in long descriptions of
 charaters) I feel that NFSv4 steps beyond the role of allowing
 clients to communicate with servers into the roles of defining a
 virtual filesystem.  Given the strong desire for interoperability, I
 think this is the wrong way to go.

 So, where I am getting to is that I think that instead of having
 "case_insensitive", we should have something like an enumerated value
 called, say "name_equivalence".

 Some values that name_equivalence could take might be:

 NAME_EQUIV_BINARY
	If two names are the same length and made of the same string
	of bits, they refer the the same file, else they may not
 NAME_EQUIV_8DOT3
        If two names each contain only charaters in the 7 bit ASCII
	set, and either
          1/ they have no period, and the first 8 characters of one
	     when shifted to US-ASCII uppercase are the same as the
	     first 8 characters of the other when shifted to US-ASCII
	     upper case
         or
          2/ they both contain a period, and the substrings before the
	     first period in each match in the manner of 1 above and
	     the first three characters of the substring after the
	     first period match when shifted to upper case
         then the names refer to the same file, else they may not
         (plus some allowance for illegal characters)

 NAME_EQUIV_WIN32
        Name equivalance should be tested using the method defined in
        the WIN32 API as recorded in RFCxxxx

 NAME_EQUIV_MAC
        Name equivalance is a using on the Macintosh operating system
        as defined in RFCyyyy

 Hopefully you can see my point.  NFSv4 should allow the server to
 tell the client what equivalence relation it is using on filenames.
 There may be several different ones "out there" and I don't think that
 it is the place of NFSv4 to define another one.
 If a server implements a relation which is not covered by the
 minor-version of NFSv4 which is beign used, it can report the minimal 
 NAME_EQUIV_BINARY and the client just might have to do a few more
 lookups. 

 On a related issue, I don't think I can see the point of
 "case_preserving", or how it is usefully different from "no_trunc",
 unless there is some standard API which presents these values (which
 I doubt).
 Both "case_preserving" and "no_trunc" say "If you create a file, then
 a readdir will list that file with exactly the name you gave", and
 that is about the only guarantee that I think would be of interested
 to any client or application.

NeilBrown