Traversing the directory hierarchy is broken on Windows as of version 0.47

[0x6675636b796f75676974687562]

Expected Behavior

Running ktlint w/o specifying any input files previously made it search for *.kt and *.kts files, starting from the current directory, e. g.:

$ ./ktlint
14:54:01.402 [main] INFO com.pinterest.ktlint.internal.KtlintCommandLine - Enable default patterns [**/*.kt, **/*.kts]
10:56:53.905 [main] DEBUG com.pinterest.ktlint.internal.KtlintCommandLine - 6821ms / 14 file(s) / 167 error(s)

This behaviour still holds when ktlint is run from the command line on Linux or Mac OS X.

Observed Behavior

Yet, using just the very same command line switches on Windows (i. e. when running ktlint from Git Bash) results in no input files being found:

15:01:09.889 [main] INFO com.pinterest.ktlint.internal.KtlintCommandLine - Enable default patterns [**\\*.kt, **\\*.kts]
15:01:10.457 [main] ERROR com.pinterest.ktlint.internal.KtlintCommandLine - No files matched [**\\*.kt, **\\*.kts]

This is a clear regression against version 0.46.1 and, apparently, has been caused by the recent changes which re-enable (sort of — see #1601) the parsing of Ant-like path patterns (e.g.: **/*.kt) — which was broken in version 0.46.1.

Steps to Reproduce

1. Download the fat JAR from https://github.com/pinterest/ktlint/releases/tag/0.47.0.
2. Run the far JAR against any non-empty codebase on Windows:

   java -Xmx512m --add-opens java.base/java.lang=ALL-UNNAMED -jar ktlint

Your Environment

• Version of ktlint used: 0.47
• Relevant parts of the .editorconfig settings: none
• Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): CLI
• Version of Gradle used (if applicable): N/A
• Operating System and version:
  • MINGW64_NT-10.0-19043 unit-725 3.3.4-341.x86_64 2022-05-09 11:56 UTC x86_64 Msys
  • Linux unit-725 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 GNU/Linux

[paul-dingemans]

I am not sure whether I can fix this soon. Biggest problem for me is that I do not have access to a Windows machine on which I can test. Also the unit testing on the windows-look-a-like-filesystem is limited. Is anybody willing to help me out by either fixing the problem or run tests whenever I have a possible fix ready?

[0x6675636b796f75676974687562]

Biggest problem for me is that I do not have access to a Windows machine on which I can test. Also the unit testing on the windows-look-a-like-filesystem is limited.

It doesn't actually matter whether any of the unit tests is successful on your or my PC, be it Windows or Linux. The only source of truth should be the CI server, and, since you're using GitHub, you can easily have one. Only when each commit to the project gets tested on the CI infrastructure can you be sure that nothing gets broken.

Please read on about Building and testing Java with Gradle, and also about Using a matrix for your jobs.

There's also plenty of examples on how to use the gradle/gradle-build-action.

[paul-dingemans]

Yes, that is already in place. But you don't have an actual filesystem in CI. So we use jimfs to simulate that. The windows version of it, lacks some functionality. So certain unit tests can not run on CI.

[0x6675636b796f75676974687562]

@paul-dingemans, thank you for the clarification.

Correct me if I'm wrong, but file system operations are allowed when using GitHub Actions — you can create/delete/append files, traverse directories etc.

Probably, FileUtilsFileSequenceTest could be extended to use not only jimfs but also the default file system. If you think the resulting test would be too heavy, then it could be extracted into a separate GitHub workflow. Or am I missing something here?

[paul-dingemans]

I would not expect it to be too heavy. I just have no experience with it. Most code in this project was written before I got involved.

If you have a reference to a project where something like this is set up, I would be happy to use that. Otherwise, I have to investigate it myself. Of course, it might take longer as a result of that. So any help is appreciated.

[0x6675636b796f75676974687562]

@paul-dingemans, I'll try to refactor a unit test and give you a clue how a default file system can be tested.

In a short while.

[paul-dingemans]

@paul-dingemans, I'll try to refactor a unit test and give you a clue how a default file system can be tested.

In a short while.

That would really be appreciated.

[paul-dingemans]

I think I have found the problems with the Unit tests for windows. It was caused by incorrect logic in the FileUtils.kt which has been present there for a long time. See #1615 for fixes related to #1600 and #1601.