开发者

C# Client - Perl server - File Path Case Sensitivity

开发者 https://www.devze.com 2022-12-12 15:12 出处:网络
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.

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 开发者_StackOverflow社区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();
        }


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.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消