ExpandPath return wrong case, when using a mapping
Description
Environment
Java 8 - 252
Lucee 5.3.7.48
Windows 10 / Ubuntu 20.04 (tested on both)
Activity
David Raschper 17 January 2022 at 12:46
@Michael Offner Thank you for the review!
The problem on case senstive file system is that test.cfm and Test.cfm could be two completly different files and therefore should have multiple instances in the pool (at least for my understanding).
INDEPENDENT of the input the result should give the real name anyway, i assume this was not done because of performance reasons.
I guess it depends on what you declare as “real name”. For me it should be the given input.
It should also not correct the input. (eg. if there is a existing Test.cfm and i do a expandPath with test.cfm (which not exist) it should also result in test.cfm and not Test.cfm, since that could be the wrong file on case-senstive systems).
Also i can use eg. expandPath without a existing file, so there would be not way to correct that.
For me it would help, if we always get our input back as absolute path (in ExpandPath).
Because currently we having problems where sometimes that wrong case is cached in the pool and we than failing to build the correct url/path.
Im not completly sure how ACF handles this, but there i get always the given input back (maybe i can go for some more research on this)
Michael Offner 17 January 2022 at 09:02
@David Raschper sorry but i could not accept this PR, here my comment in the PR why:
This change would make the page pool case sensitive and cause multiple instances of the same page in the pool, but that is not expected. So let say you have this code
<cfinclude template="test.cfm">
<cfinclude template="Test.cfm">
If "test.cfm" is changed the second include would still show the old code, because the flush record would only flush one of the 2 records in the pool. This change would break the pool and blow it up.
INDEPENDENT of the input the result should give the real name anyway, i assume this was not done because of performance reasons.
Thanks for your PR, but sorry we cannot accept this.
David Raschper 22 December 2021 at 13:37
Pull-request: https://github.com/lucee/Lucee/pull/1496
I tested it on ubuntu and windows and its now always returning the correct path.
The problem was that the map-keys for the pagesources are always lowercase, which than return wrong pagesources for case-senstive filesystems.
Also i checked the ticket https://luceeserver.atlassian.net/browse/LDEV-869 which leads to the lowercase change.
I tried to reproduce the described issue. On windows im not able to reproduce the problem (version 5.3.9.23 and the version with my fix). While on ubuntu i kinda can reproduce it on 5.3.9.23 and my version (so it seems not related to the map-keys). When accessing the file test.cfm with test.cfm and TEST.cfm it both works. After change the file to TEST.cfm and then access test.cfm or TEST.cfm it both failes (MissingIncludeExpection while the file is available).
But it seems to be another problem and not related to the map-keys for the pagesources. I guess thats the change in the PageSourceImpl in the getPhyscalFile() function, which skips the processing when the physcalSource is not null.
Pothys - MitrahSoft 18 March 2021 at 10:01
I've checked this ticket and confirmed the issue happened on lucee latest version 5.3.8.159-SNAPSHOT also. ExpandPath() with mapping returns result with the filename in uppercase and extension in lowercase. Seems, ACF returns a result with case sensitivity. This regression starts from 5.1.2.20-SNAPSHOT onwards.
Might be this commit causes the issue
https://github.com/lucee/Lucee/commit/d4748f9d55898f47f22406195064ea5a13223eef
I added a testcase to this ticket:
Pull Request: https://github.com/lucee/Lucee/pull/1237
Details
Assignee
Michael OffnerMichael OffnerReporter
David RaschperDavid RaschperPriority
MajorLabels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Affects versions
Details
Details
Assignee
Michael OffnerReporter
David RaschperPriority
MajorLabels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
When using expandPath-Function with a mapping, the character-case is not as expected.
Example (/test2 is a mapping):
<cfdump var="#ExpandPath("TEST.test")#"/> <cfdump var="#ExpandPath("Test.test")#"/> <cfdump var="#ExpandPath("/test2/TEST.test")#"/> <cfdump var="#ExpandPath("/test2/Test.test")#"/> <cfdump var="#ExpandPath("/test2/TesT.test")#"/>The expect output should be:
/opt/lucee-express-5.3.7.48/webapps/ROOT/TEST.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/Test.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/TEST.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/Test.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/TesT.test
But following data will get returned:
/opt/lucee-express-5.3.7.48/webapps/ROOT/TEST.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/Test.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/TEST.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/TEST.test
/opt/lucee-express-5.3.7.48/webapps/ROOT/test22222/TEST.test
It looks like the first expandPath caches the output for the next ones.
But that can lead to an unexpect behavior. On a case-senstive system it causes problems, when the wrong entry gets cached.
This only happens when using a mapping.