It appears jnr-posix JavaSecureFile will strip off the extra slash erroneously here.

Actually two things to point out in this issue:

1. java.io.File actually exhibits the bad behavior too:

jruby -e 'f = java.io.File.new("../snippets/cp2.rb/"); p f.exists?'
true

cp2.rb is a regular file. It is possible we can just secondarily always check isDirectory() here and then throw ENOTDIR.

2. The bad behavior in 1 actually strips out the / when it normalizes the path. So even if we use the path from this file to call a native stat() we have already stripped the trailing / so we cannot know to ENOTDIR.

The base reported problem is this should not stat but it is coupled with proper return value as well. is cp2.rb did not exist we should return ENOENT but if it does exist we should return ENOTDIR.

Since we have had this problem perhaps for the entire length of JRuby I am not prioritizing this for the current release.

@enebo shouldn't cruby resolve the path and return true?

@sumitmah you can raise it as an issue no cruby's site as a bug and see if they agree or not. I don't actually understand why they return false. It could be as simple as they split on / and get '' as name?

@enebo as per the ruby-doc “file exists” means that stat() or fstat() system call is successful. And since java normalises the file path before resolving I think we need to have explicit check if we want to be consistent with mri. What do you think?

A consistent check would be a one-off, but perhaps it could be written into the contract of JavaSecuredFile or a similar utility. It does seem like a weird choice on the Java side, but I guess they figured no systems can have both a file and a dir of the same name, so removing the trailing element should not be meaningfully different to the FS.