Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amend description of FilenameUtils#getFullPathNoEndSeparator(String) to reflect correct named user result with trailing slash #553

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Philzen
Copy link

@Philzen Philzen commented Jan 4, 2024

Similar to #551, the trailing slash is actually preserved in the result here.

Confirmed to have this behaviour in 2.4 and latest 2.15.1

@@ -669,7 +669,7 @@ public static String getFullPath(final String fileName) {
* ~ --> ~
* ~/ --> ~
* ~user --> ~user
* ~user/ --> ~user
* ~user/ --> ~user/
Copy link
Member

@garydgregory garydgregory Jan 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes the Javadoc to contradict itself with the above's excluding the final directory separator.
The question is whether Windows's "C:\" unchanged output is a special case or a bug.
CC: @elharo

Copy link
Contributor

@elharo elharo Jan 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing javadoc and API is very unclear. I do not understand "Gets the full path from a full fileName, which is the prefix + path, and also excluding the final directory separator."

The argument is not a filename. There is no such thing as a "full path" in normal parlance. Bug filed. https://issues.apache.org/jira/browse/IO-836

I also agree that if this method turns ~user/ into ~user/ that's a bug. It should produce ~user.

C:\ should also (80% certainty) turn into C:, not C:\

I further expect there are additional bugs in this method involving Unix shell conventions and platform dependencies, but I'd have to dig into the rest of the class to understand exactly what those are.

What a tasty can of worms you've opened. :-)

@garydgregory garydgregory changed the title Amend description to reflect correct named user result with trailing slash Amend description of FilenameUtils#getFullPathNoEndSeparator(String) to reflect correct named user result with trailing slash Jan 4, 2024
@@ -669,7 +669,7 @@ public static String getFullPath(final String fileName) {
* ~ --> ~
* ~/ --> ~
* ~user --> ~user
* ~user/ --> ~user
* ~user/ --> ~user/
Copy link
Contributor

@elharo elharo Jan 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing javadoc and API is very unclear. I do not understand "Gets the full path from a full fileName, which is the prefix + path, and also excluding the final directory separator."

The argument is not a filename. There is no such thing as a "full path" in normal parlance. Bug filed. https://issues.apache.org/jira/browse/IO-836

I also agree that if this method turns ~user/ into ~user/ that's a bug. It should produce ~user.

C:\ should also (80% certainty) turn into C:, not C:\

I further expect there are additional bugs in this method involving Unix shell conventions and platform dependencies, but I'd have to dig into the rest of the class to understand exactly what those are.

What a tasty can of worms you've opened. :-)

@garydgregory
Copy link
Member

Note that we should not treat ~ in any special way since it is a Unix-like shell utility and not a file system functionality.

@Philzen
Copy link
Author

Philzen commented Apr 24, 2024

@elharo @garydgregory i totally see the points you've raised and agree it may be worth tackling the current behaviour in a bugfix.

However, until that happens, i believe it will be worthwhile to sync the JavaDoc with the current behavior to minimize bad surprises when consuming the library.

@garydgregory
Copy link
Member

Hello @Philzen
It looks to me like git master already contains the Javadoc change. What about all the callers of the API?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants