-
-
Notifications
You must be signed in to change notification settings - Fork 921
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
MRI and JRuby disagree about File.exist?("/non_directory_file.name/") #4403
Comments
It appears jnr-posix JavaSecureFile will strip off the extra slash erroneously here. |
Actually two things to point out in this issue:
cp2.rb is a regular file. It is possible we can just secondarily always check isDirectory() here and then throw 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? |
…e> ending with / should return false
@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. |
Here's MRI
And both 9.1.5.0 and 1.7.19 ( the two versions we use around here) ...
The text was updated successfully, but these errors were encountered: