I know, I *stalk* that project, sue me...
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
We'll we just better keep quiet about our stalked projects or we'll start seeing words like Python, Lua, Go, C++, Java and who knows what other non-Ruby things ;)
Interesting that his reply to you was "...more bug free." Anything relevant to helping Fenix's path handling?
Jon
:-$
> Interesting that his reply to you was "...more bug free." Anything relevant to helping Fenix's path handling?
>
Actually is more in the line of the work done by Dusan in work with
faster winnt_stat implementation.
Note that they moved from FindFirstFile (globbing operation) to use
CreateFileW with OPEN_EXISTING, something similarly done by Hiroshi
with rb_file_load_ok.
It can also help Fenix to avoid GetLongPathName over non-existing path.
Need to work a bit more on this specially considering the tests added
to cover File.expand_path exposed by Yura.
Right now I'm working on something else but promise will catch up soon ;-)
> Note that they moved from FindFirstFile (globbing operation) to use
> CreateFileW with OPEN_EXISTING, something similarly done by Hiroshi
> with rb_file_load_ok.
FindFirstFile is slow, globing and high level.
What is interesting is that now FindFirstFile() it is not used in their stat().
Does that mean that CreateFileW() and GetFileInformationByHandle do
the same as FindFirstFile, but without globing overhead? Are there
points of "but it wont work with network files, dirs, atributes..."?
Also, it should be measured. It may be that CreateFile+GetInfByHandle
is in fact slower that GetFileAttributsEx, since documented WinAPI is
just a subsystem over NT API, and former call could simply be
optimized to do the same in less calls.
> It can also help Fenix to avoid GetLongPathName over non-existing path.
For vista and up there is GetFinalPathNameByHandle()