Hello,

Thank you for the explanation, Luis.

In message "[ruby-core:47021] [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows"
    on Aug.06,2012 23:02:11, <luislavena / gmail.com> wrote:
> Since this patch no longer hits the filesystem to determine if the path is a real file and expand the shortname into longname, we moved it to WEBrick.

I see.


> Our decision to maintain WEBrick tests was under the assumption that the test was doing something other than what Rack is doing here.
> 
> Because of that, we decided to only expand the shortnames in WEBrick.

I understand, probably :)


> IMO think Rack approach is better, as it doesn't rely on File.expand_path at all, but I could be wrong.

Normally we should not depend on the path normalization function
of File.expand_path.
Each program should perform peculiar safing processing which each
needs.
Therefore, I think that the approach of Rack may be better, too.

However, it is very difficult to write safe code because there
are too many traps in the file system of Windows.
It's impossible for non-Windows programmers in particular.
For instance, your WEBrick patch calls Win32 API with DL,
but Unix programmers will not know Win32 API.
Therefore, we made decision of pushing all the troubles in
File.expand_path.
We expected to help to write safe code in almost all cases.

Possibly this was not a good message.
Much program depending on File.expand_path may have been made
in the world.
It's the reason why I am very cowardly to change the behavior
of File.expand_path.


But I am not against to this patch.
I hope another people's review based on the above viewpoint.


Regards,
-- 
U.Nakamura <usa / garbagecollect.jp>