When path parts are provided to the "add" command, Fossil should query the OS and use case pattern as returned by the OS, not as provided on the command line.

Is the current approach breaking one of your repos or is the InConSisTent caSiNg what amounts to a cosmetic issue? It's been using the current approach for 16+ years without any known functional issues.

The implication of the OP’s complaint is that on checkout, the directory gets called “scripts”, lowercase.

If the checkout machine isn’t case-insensitive, it isn’t a purely cosmetic issue.

Wasn't there a discussion here a while back where somebody had managed to create a repository containing two directories differing only in case? It evolved into a general discussion about whether Fossil should be file system agnostic.

My guess is the OP has ended up with this, and realised that while a subsequent checkout appears to work you end up with a single directory with merged files (on Windows anyway). And you cannot easily predict which version of the 'same' name it will have.

I suspect any attempt to "fix" this will run into any number of nasty edge cases, as in essence what we are saying is use the canonical path that the supplied path refers to - which begs questions about symbolic links and relative paths.

I ended up having two directories in the repo differing only in case. I just deleted the repo and started over. I do not know what issues it might have caused in the future, but this is definitely wrong. And the fact that Fossil does not even issue a warning when case sensitivity is not enabled is not good either.

I ended up having two directories in the repo differing only in case

How would fossil know that's not what you wanted to do?

What OS are you using?

I am using Windows. I have case sensitivity disabled, so no matter Fossil should not create in the repo paths only differing by case.

What is the API to use to query that OS to find out what it thinks the preferred case should be? I presume that the API will be different on Unix and Windows.

I am not a C coder. One way to do this on Windows is changing to the target directory and getting the current directory. So for request

fosssil add ./scripts/*.*

you would get the prefix, "./scripts", change into "./scripts", and query the current directory. At the same time, if you simply use the basic file search API, like (FindFirstFileA)[https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilea] and (FindNextFileA)[https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilea], I assume it should return proper case.

On Unix/Linux with case-sensitive file system this algorithm would fail, if the correct case is not supplied in the first place. But on case-sensitive file system there is no guarantee that there is only one case variant of the given actual path to start with. So whether anything should be done here on UNIX/LINUX is a question.

Please compile the latest check-in on the preserve-case-on-add branch and report back whether or not this resolves your issue.

I can confirm that the patched Windows version correctly preserves case of both directory and file names. Thank you!