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

Jump to bottom

isfile() now throws an error on Windows #26685

Closed
staticfloat opened this issue Apr 2, 2018 · 4 comments · Fixed by #31999
Closed

isfile() now throws an error on Windows #26685

staticfloat opened this issue Apr 2, 2018 · 4 comments · Fixed by #31999
Labels
filesystem Underlying file system and functions that use it regression Regression in behavior compared to a previous version windows Affects only Windows

Comments

@staticfloat
Copy link
Sponsor Member

On Windows, isfile() now throws an error when given an "invalid argument".

On 0.6:

julia> isfile("http://google.com")
false

On 0.7:

julia> isfile("http://google.com")
ERROR: stat: invalid argument (EINVAL)
Stacktrace:
 [1] stat(::String) at .\stat.jl:68
 [2] isfile(::String) at .\stat.jl:303
 [3] top-level scope
@ararslan ararslan added windows Affects only Windows regression Regression in behavior compared to a previous version filesystem Underlying file system and functions that use it labels Apr 3, 2018
@StefanKarpinski StefanKarpinski added this to the 1.0.x milestone Apr 3, 2018
@ararslan ararslan mentioned this issue Apr 3, 2018
Closed
@staticfloat
Copy link
Sponsor Member Author

This is kind of weird; GetLastError(), after calling CreateFileW(), is giving two different answers for identical inputs. It all boils down to this call on 0.7, and the analogous call on 0.6. The result of GetLastError() when req->file.pathw == L"http://google.com" is -4058 (Base.UV_ENOENT) on 0.6, but is -4071 (Base.UV_EINVAL) on 0.7.

Is there some kind of "win32 API version" that we're targeting that is causing this difference? We could, of course, add Base.UV_EINVAL to this list to patch over the behavior change, but somehow I don't think that's the right solution.

staticfloat added a commit to JuliaPackaging/BinaryProvider.jl that referenced this issue Apr 3, 2018
@staticfloat
Work around JuliaLang/julia#26685
4f3b057
staticfloat added a commit to JuliaPackaging/BinaryProvider.jl that referenced this issue Apr 3, 2018
@staticfloat
Merge pull request #56 from JuliaPackaging/sf/safe_isfile
08a314a 
Work around JuliaLang/julia#26685
@jebej
Copy link
Contributor

jebej commented Apr 7, 2018

This might have been changed here: libuv/libuv#1088

@justinmk justinmk mentioned this issue Jun 6, 2018
Closed
@KristofferC KristofferC mentioned this issue Jun 30, 2018
Closed
visr added a commit to visr/BinaryProvider.jl that referenced this issue May 10, 2019
@visr
workaround isfile throwing on Windows
556c442 
See JuliaLang/julia#26685. Uses the workaround from JuliaPackaging#56.
@staticfloat
Copy link
Sponsor Member Author

Thanks @jebej, that is indeed the source of the issue.

staticfloat added a commit that referenced this issue May 10, 2019
@staticfloat
base/stat.jl: Mask UV_EINVAL error codes for jl_sizeof_stat
03463ec 
This fixes #26685, where libuv
decided to throw `UV_EINVAL` on windows for invalid-filepaths such as
`foo??` or `http://google.com`, instead of returning `UV_ENOENT` as they
were previously [0].  This causes windows to throw errors on calls such
as `isfile("http://google.com")`, whereas other platforms simply return
`false`.  This change simply ignores `UV_EINVAL` alongside the other
"allowed failure" error codes.

[0] libuv/libuv#1088
staticfloat added a commit that referenced this issue May 10, 2019
@staticfloat
base/stat.jl: Mask UV_EINVAL error codes for jl_stat
6f6a30d 
This fixes #26685, where libuv
decided to throw `UV_EINVAL` on windows for invalid-filepaths such as
`foo??` or `http://google.com`, instead of returning `UV_ENOENT` as they
were previously [0].  This causes windows to throw errors on calls such
as `isfile("http://google.com")`, whereas other platforms simply return
`false`.  This change simply ignores `UV_EINVAL` alongside the other
"allowed failure" error codes.

[0] libuv/libuv#1088
@staticfloat staticfloat mentioned this issue May 10, 2019
Merged
staticfloat added a commit that referenced this issue Jun 20, 2019
@staticfloat
base/stat.jl: Mask UV_EINVAL error codes for jl_stat
1abeeb7 
This fixes #26685, where libuv
decided to throw `UV_EINVAL` on windows for invalid-filepaths such as
`foo??` or `http://google.com`, instead of returning `UV_ENOENT` as they
were previously [0].  This causes windows to throw errors on calls such
as `isfile("http://google.com")`, whereas other platforms simply return
`false`.  This change simply ignores `UV_EINVAL` alongside the other
"allowed failure" error codes.

[0] libuv/libuv#1088
@vtjnash
Copy link
Sponsor Member

vtjnash commented Jan 6, 2020

FYI libuv/libuv#2375 and libuv/libuv#2601

@timholy timholy mentioned this issue Sep 6, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
filesystem Underlying file system and functions that use it regression Regression in behavior compared to a previous version windows Affects only Windows
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

base/stat.jl: Mask UV_EINVAL error codes for jl_stat JuliaLang/julia
5 participants
@staticfloat @StefanKarpinski @vtjnash @ararslan @jebej