GH-11121: Fix SftpSession.listNames() for root directory wildcard paths

[yangadam]

Summary

SftpSession.listNames("/*") throws SftpException: SSH_FX_NO_SUCH_FILE because the path parsing in SftpSession.list() uses lastIndex > 0 to detect the / separator. For root-level paths like /*, lastIndexOf('/') returns 0, which is excluded by the > 0 check. This causes the entire path /* to be treated as a literal directory name instead of being split into directory / and file pattern *.

Changes

• Changed lastIndex > 0 to lastIndex >= 0 in SftpSession.list() so root directory paths are correctly parsed
• Added test lsRootWildcard() that reproduces the issue and verifies the fix

Fixes: gh-11121

Signed-off-by: Adam Yang yangadam@users.noreply.github.com

[artembilan]

Well, looks like you have not checked the fix locally before opening PR:

SftpOutboundTests > testFtpOutboundGatewayInsideChain() FAILED
    org.springframework.messaging.MessageHandlingException at SftpOutboundTests.java:192
        Caused by: org.springframework.messaging.MessagingException at SftpOutboundTests.java:192
            Caused by: java.lang.NullPointerException at SftpOutboundTests.java:192

Please, ensure you run ./gradlew "spring-integration-sftp:check locally before pushing to PR.

Thanks

[yangadam]

Well, looks like you have not checked the fix locally before opening PR:

SftpOutboundTests > testFtpOutboundGatewayInsideChain() FAILED
    org.springframework.messaging.MessageHandlingException at SftpOutboundTests.java:192
        Caused by: org.springframework.messaging.MessagingException at SftpOutboundTests.java:192
            Caused by: java.lang.NullPointerException at SftpOutboundTests.java:192

Please, ensure you run ./gradlew "spring-integration-sftp:check locally before pushing to PR.

Thanks

Thanks for running the build. After debugging, I found that the failure was caused by the lack of mocking for the stat method, which previously was not called when the path was /remote-test-dir/.

I can add the mocking, but I need to confirm whether it is acceptable to call stat whenever the path is /remote-test-dir/ or /remote-test-dir/remote-sub-dir/.

@artembilan

[artembilan]

I need to confirm whether it is acceptable to call stat whenever the path is /remote-test-dir/ or /remote-test-dir/remote-sub-dir/.

Correct. So, ask yourself if it is valid to divide /remote-test-dir into / and remote-test-dir as you do in your current fix.
You covered with boolean isPattern = remoteFile != null && remoteFile.contains("*");.
But that is not OK for a dir request.

I think we need just trim both leading and trailing / in the method you have modified instead.
Something like:

String remotePath = StringUtils.trimLeadingCharacter(StringUtils.trimTrailingCharacter(validPath, '/'), '/');

With that your /* will become * as you expect.

[yangadam]

Hi @artembilan, thanks for taking the time to review and for the suggestion!

I looked into the trimming approach, but I think the split-then-stat pattern might actually be unavoidable here. A name like remote-test-dir could be either a file or a directory — we can never know beforehand without calling stat.

In fact, the existing code on main already does this for deeper paths. For example, /remote-test-dir/remote-sub-dir/ goes through the same flow:

1. trimTrailingCharacter → /remote-test-dir/remote-sub-dir
2. lastIndex = 21 (> 0), so remoteDir = "/remote-test-dir", remoteFile = "remote-sub-dir"
3. isPattern = false → enters the stat block → discovers it's a directory → reassigns remoteDir = remotePath

My fix for lastIndex == 0 simply makes /remote-test-dir follow the same existing pattern — the only difference is the nesting depth. In both cases, the last path component could be a file or a directory, and stat is how the code figures that out.

Would it be OK to keep this approach consistent with the existing behavior for now, and refactor the method later if we'd like to optimize it?

[artembilan]

Please, add your name to the @author list of all the affected classes.

Then we'll merge.

Thank you!