This is fossil version 2.22 [66ee0beb9b] 2023-05-31 15:26:08 UTC Running Cygwin on Windows 10

I went into the ui for my project to look at files. I was looking at a listing of my folders and files. What a surprise to see a folder named Build and another one name build, The build folder contained the latest executable that I added to fossil; the Build folder contained the rest.

There is, of course, only one such folder in reality and it is named "Build".

So how do I fix this in the library? And why did fossil do this? Did I cause it?

And why did fossil do this?

Because fossil is case-sensitive by default. According to the docs for the case-sensitive setting, that should be disabled on cygwin by default, but perhaps yours is in case-sensitive mode. Please try, from a checkout:

$ fossil set case-sensitive
# it will show you any current value. If it shows none, it's using the default.
$ fossil set case-sensitive 0

case-sensitive was null. I have half a dozen repos, and none have set case-sensitive. And I run them all under Cygwin. Only one has sub-folders - the one with Build/build.

I set case-sensitive in that one to 0. The UI still shows the two forms of the build folder. What do I do to fix the library so there is only one build folder?

What do I do to fix the library so there is only one build folder?

It doesn't look like you can. Fossil remembers names case-sensitively, it just ignores those cases in many contexts on Windows. The /dir code, it turns out, it does not ignore case-sensitivity, but it looks like that will be straightforward to resolve... bbl.

The /dir code, it turns out, it does not ignore case-sensitivity, but it looks like that will be straightforward to resolve... bbl.

Nevermind :/. It's not simply a matter of resolving the SQL to be case-insensitive (which is a 1-line fix), but also refactoring /dir to be able to understand that there may be multiple entries for a give case-insensitive name and knowing how to deal with that (but see below). For example, the SQL is easily taught that 'Build' and 'build' are equivalent, so /dir renders only the first of those it sees: 'Build'. When you click on 'Build', the name given over to the next page view is 'Build', not 'build', so it will visit the 'Build' directory.

If we make the /dir view case-insensitive, it becomes impossible to browse same-named directories without more significant underlying changes in /dir which enable it to merge the views of multiple case-differing names into one view. That, however, opens up an ugly corner case...:

+ Build
  -- foo
+ build
  -- Foo

Dir cannot, if it is case-insensitive, unambiguously render that listing. When it's told to browse to 'Build', it could only show one of 'Foo' and 'foo' so the user would be unable to reach that file via /dir.

I took a chance on doing this and it worked! Now there is only on build folder shown in the UI and it is named Build:

fossil mv build/png2ico.exe Build/png2ico.exe

To test case-insensitivity (with case-sensitive (local) 0), I added a real (dummy) file xxx.txt in the 'Build" folder. Then I told fossil to add 'build/xxx.txt' and checked-in the add. When I went to the UI to view files there were, once again, two folders, 'build' and 'Build'. This is obviously a bug in fossil. I'll just have to remember to use the correct case when referring to that folder name.

Some place in the fossil docs, a CAUTION should be given about using case-sensitive folder (and I assume, file?) names. The caution would be to always use the correct case-sensitive name when dealing with the file, irrespective of the state of the case-sensitive option.

...The /dir code, it turns out, it does not ignore case-sensitivity

Shouldn't this be a problem rather somewhere at the "add" command level?

User added a file with a path within case-insensitive "Build" directory. So such path has to default to either lowercase or some "ignore-case" form before it's stored in the repo tree.

"/dir" seems to do the job correctly based on paths stored in the repo tree. This case-ambiguity needs to be solved at the time of "add".