views:

221

answers:

3

We have a C# .Net client application that sends some commands via REST over HTTP. The server is on a Linux machine written in Perl.

These commands contain file paths located on the server that can be entered by the user. Since the users are on windows, we'd like for them to be case-insensitive, but this is giving us some issues in locating the files server side.

How can we get the correct casing?

We have 2 possible solutions:

  • Use a winapi call on the client to fix the path to be properly cased. (These files are visible by a shared folder on the clients computer)

  • Use some perl code on the server to locate a file with a case-insensitive path as input

Any suggestions? We would like this to work on all client machines that are Windows XP SP2 and higher.

UPDATE: We decided it should be fixed client side, on the rare case that there is a case mismatch.

We run this if we get a "file not found" error on the directory of the file. Someone would have to modify this to work for files as well, but in our case the filename could never be wrong (I'd rather not explain why):

        string FixDirectory(string fullpath)
        {
            return fullpath
                .Split(Path.DirectorySeparatorChar)
                .Skip(1)
                .Select(path =>
                    {
                        string[] split = fullpath.Split(new string[] { path }, StringSplitOptions.None);
                        string tempDir = split[0];
                        string[] dirs = Directory.GetDirectories(tempDir, path);
                        fullpath = fullpath.Replace(Path.Combine(tempDir, path), dirs[0]);
                        return fullpath;
                    })
                .Last();
        }
+1  A: 

This sounds like a job for the server. If you give a case sensitive server a case insensitive string, it can more easily find the desired file than the client can.

McKay
But what if the server has a file named MyFile.txt and also a file names myfile.txt. How can we prevent overlap?
Jonathan.Peppers
@Jonathan - you can match on case-sensitivity first then on a case-insensitive match if the first fails. Beyond that, consider a different naming scheme or directory structure.
Austin Salonen
Yes:What if the server hasMyFile.txt, myfile.txt, and MYFILE.TXTand the user passes in mYfIlE.tXt. The server will have to decide what to do. What do you want it to do?
McKay
Normalizing the incoming data on the server to be case insensitive avoids all the collision errors. Make both systems case insensitive--provide a well defined and consistent way to convert arbitrary input to server compatible case.
daotoad
+2  A: 

Your first proposal makes sense -- if the client can see the file, then use an API call on the client to get the real filename (with the correct case) before submitting that data to the server. The user shouldn't have to manually type in a filename at all - use the standard "Browse..." widget to bring up a dialog box that allows the user to find the file in his filesystem.

Using a case-insensitive file search on the case-sensitive server should only be a last resort. As you mentioned in your follow-up comment, there are various edge cases that are annoying to account for, so it would be best to avoid this scenario entirely.

Ether
We are making the client do a quick directory lookup to fix the problem if there is a rare casing mismatch, I'll post on my edit.
Jonathan.Peppers
+1  A: 

Can you normalize the character cases on your server? For example, force all directory and file names to be lowercase.

If so, then your server process would easily convert requests for My/FILE.XLS and my/file.XLS to my/file.xls.

Normalization avoids a lot of complicated search logic and it prevents collisions between similar file names.

daotoad