So I thought I had this working and my tests were passing on Windows, but they failed on Linux in our CI. I added a check whereby if the expanded path exists on disk, we call getRealPath() on it, which provides the actual path on disk. For a real path of C:/foo/bar this works fine when the expanded path is C:/FoO/bAr/ but for Linux it’s a catch-22. Using the example in the ticket, if the expanded path is /app/model/ReportBuilder but the actual path on disk is /app/model/reportBuilder then it doesn’t exist and my .getRealPath() call never kicks in. ]

This actually brings up some questions about how CF even does this. I know that looking up cfm or CFC files is case insensitive for Adobe and Lucee, but I was never aware of expandPath() having any case insensitive checks (which requires a slower approach of analyzing the path from the root folder downward, performing a directory listing at each level, and then manually looping and doing case insensitive searches for the next folder path as you go.

That’s the only way I know of that BoxLang can “detect” if there is another similar file path on disk with a different case than the one passed in, but I really didn’t think CF did any of that This is unfortunately a bit of a pain to test on Linux as trycf.com blocks use of the expandPath() BIF. Can you confirm you are seeing this behavior on Linux and not just Windows? Do Adobe and Lucee both perform these case insensitive searches on Linux regardless of the input casing to the BIF?

revising issue description

Huh? Sorry, I’m not following. I can’t tell from the ticket exactly what is happening and what needs to happen differently. When I asked which one matches the actual file system, I mean is the actual real folder on the hard drive called /app/model/reportBuilder (lowercase “r”) or is it called /app/model/ReportBuilder (upper case “R”) ?

I’m unclear if Lucee is keeping the case of the input to the function or getting the “Real path” (as Java calls it) from the file system. Keeping in mind, of course, you can expand non-existent paths.

Or is the case not even the issue? I just don’t know what “example of unexpected results of expandPath behavior” means in this case. What specifically about the result is unexpected based on what specific local criteria? The sample code, as it stands, isn’t something I can just paste in and test without knowing what your local file system has that you’re testing on and what specific behavior you’re expecting to happen outside of “just match Lucee”

Sorry, right. Lucee has the correct answer here.

Which one matches the actual file system?