8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl #90
This patch tweaks
The check in the implementation is heavily borrowed by what
The test simply check that paths coming from the (internal) JRT file system are not supported by the factory.
uschindler left a comment •
Looks fine to me.
Another option would have been to just check the class with instanceof. If the FileChannel returned by the path's filesystem has wrong type, it won't work. If we have some custom filesystem that just returns the original FileChannelImpl but does some additional checks before or after (e.g to hide some files from user), this would still work.
But I think it's better to be clear here and deny anything which is not default operating system filesystem, until we have a better solution.
In Lucene I added some hack that removes our test-only filesystem wrappers from the path. I will later go the route to mark those path instances with some interface Unwrappable that provides a method unwrap().
We considered this - but we opted for better clarity and alignment with existing APIs.
@mcimadamore This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 16 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
@mcimadamore Since your change was applied there have been 16 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit d60a937.