Directory.dir_exists() always fails on res:// type paths even though Directory.open() works

[maeb]

Operating system or device - Godot version:
Windows 10, Godot 2.1 alpha custom build

Issue description (what happened, and what was expected):

directory = Directory.new()
if not directory.dir_exists("res://path/to/dir"):
   print ("Directory does not exist")
if directory.open("res://path/to/dir) == OK:
  print("Directory open works")

Output:
Directory does not exist
Directory open works

Expected:
Directory open works

Steps to reproduce:

directory.dir_exists(directory.get_current_dir())

Link to minimal example project (optional but very welcome):

[maeb]

The fix_path(p_dir) call in core/drivers/windows/dir_access.cpp (dir_exists function) does not touch anything when using "res://" on directory access.

directory.open() calls create_for_path in core/os/dir_access.cpp which set _access_type to ACCESS_RESOURCE then da->change_dir() calls fix_path and now "res.//" is replaced with "". Thats why directory.open() works while directory.dir_exists() fails on "res://" type paths.

directory.get_current_dir() returns "res://" so directory.dir_exists(directory.get_current_dir()) always fails on "res://" type paths.

I still don't understand why it works when running from the editor (and not after exporting)

[vnen]

I still don't understand why it works when running from the editor (and not after exporting)

When running in editor, res:// is an actual directory (your project dir). When exported, be it .pck, .zip or .exe, there's no actual directory, only a single binary file. If dir_exists rely on the OS filesystem functions, this is expected result.

I can't really tell if this is intended behavior. Technically you have full control of res:// (especially in binary formats) and have no need to check if a certain directory exists. But to just fail seems weird for me.

[maeb]

But to just fail seems weird for me

In case I was misunderstood: The call does not fail but returns false when one would expect it to return true.
It's weird to be able to open a directory path which reportedly does not exist.

[vnen]

In case I was misunderstood: The call does not fail but returns false when one would expect it to return true.

Yes, that's what I understood. I meant it shouldn't silently return false.