Skip to content

IO-872: PathUtils.directoryAndFileContentEquals with different FileSystems#732

Closed
dsmiley wants to merge 3 commits intoapache:masterfrom
dsmiley:IO-872-directoryAndFileContentEquals
Closed

IO-872: PathUtils.directoryAndFileContentEquals with different FileSystems#732
dsmiley wants to merge 3 commits intoapache:masterfrom
dsmiley:IO-872-directoryAndFileContentEquals

Conversation

@dsmiley
Copy link
Copy Markdown
Contributor

@dsmiley dsmiley commented Mar 23, 2025

@garydgregory
Copy link
Copy Markdown
Member

@dsmiley Please see the build failures.

@dsmiley
Copy link
Copy Markdown
Contributor Author

dsmiley commented Mar 24, 2025

I'll get back to this eventually... I can see a Java 8 issue, and a Windows issue.

@garydgregory
Copy link
Copy Markdown
Member

garydgregory commented Mar 24, 2025

@dsmiley

OK, sounds good. We'll be here 😉 You might want to change the state of this PR to "Draft".

} else if (pathA.getFileSystem().getSeparator().equals(pathB.getFileSystem().getSeparator())) {
// Separators are the same, so we can use toString comparison
if (!pathA.toString().equals(pathB.toString())) {
return false;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@dsmiley
This doesn't (based on local testing) when you compare two directories like "foo" and "foo/".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hm, the binary search in directoryAndFileContentEquals will also need a custom comparator or you get a ProviderMismatchException like:

java.nio.file.ProviderMismatchException
	at com.sun.nio.zipfs.ZipPath.checkPath(ZipPath.java:393)
	at com.sun.nio.zipfs.ZipPath.compareTo(ZipPath.java:620)
	at com.sun.nio.zipfs.ZipPath.compareTo(ZipPath.java:59)
	at java.util.Collections.indexedBinarySearch(Collections.java:228)
	at java.util.Collections.binarySearch(Collections.java:215)
	at org.apache.commons.io.file.PathUtils.directoryAndFileContentEquals(PathUtils.java:711)
	at org.apache.commons.io.file.PathUtils.directoryAndFileContentEquals(PathUtils.java:675)
	at org.apache.commons.io.file.PathUtilsContentEqualsTest.testDirectoryAndFileContentEqualsDifferentFileSystems(PathUtilsContentEqualsTest.java:115)
	at java.lang.reflect.Method.invoke(Method.java:503)
	at java.util.ArrayList.forEach(ArrayList.java:1259)
	at java.util.ArrayList.forEach(ArrayList.java:1259)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Hmm. In my (limited) experience looking at Path with say mac/unix, there's never a trailing slash in path.toString(). (Maybe I could be wrong). Maybe this isn't universally true... which sucks because Path is supposed to be an abstraction

Copy link
Copy Markdown
Member

@garydgregory garydgregory Apr 4, 2025

Choose a reason for hiding this comment

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

@dsmiley
It's worse than that: Path implementations are OS specific and separators are not normalized such that, for example, on macOS: Paths.get("\\foo").normalize().equals(Paths.get("/foo").normalize()) returns false.

You also need to account for ZipPath, and those end in a '/' for folders...

@garydgregory
Copy link
Copy Markdown
Member

Hello @dsmiley

I think we can close this PR based on the state of git master.
WDYT?

@garydgregory
Copy link
Copy Markdown
Member

Closing: No feedback in months.

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.

2 participants