On 22 April 2010 00:09, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Mike Meyer wrote:
I'm talking about the case where the developer knows he wants case sensitivity. In that case, you have to know whether or not the file system is case sensitive to know whether or not "file.c" would get opened if the application tried to open "file.C".
What? I thought the use case we were talking about is where you have a filename and you want to make a guess about what kind of data it contains, based on the extension.
I believe that the use case being discussed goes as follows: 1. User supplies name FILE.C to the program 2. Program has different behaviours for .c and .C files 3. Program needs to decide whether to use the .c or .C behaviour Option 1 is to use .C always on the basis that you believe that the user should expect case sensitive behaviour. Option 2 is to acknowledge that if the filesystem is case insensitive, the user will expect the same behaviour for both .c and .C files (assume .c is the "obvious" one) and do that. Note that with option 2, the user isn't necessarily being perverse by expecting .c behaviour. Maybe a legacy program created the file, using the all-uppercase name, and the user didn't (want to, remember to) change it. Maybe the user had caps lock on by accident, and doesn't want to waste time correcting the whole line. The point is that users using a case insensitive filesystem have a reasonable expectation that that programs will ignore the case of filenames (even in cases where they don't have to do so). Violating that expectation is bad. A second use case: 1. User has a directory containing a number of temporary files, all with extension .tmp (but in varying case) 2. User has a "cleanup" program which deletes temporary files The user will quite reasonably expect the cleanup program to delete all files with extension .tmp, regardless of the case. Essentially, in this simplified example, any behaviour that differs from DEL *.TMP would be considered a bug. Hope this clarifies things a bit. Paul