[ruby-core:47055] Re: [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows

On Tue, Aug 7, 2012 at 4:28 AM, U.Nakamura <[e-mail]> wrote:
> Hello,
>
> In message "[ruby-core:47045] [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows"
>     on Aug.07,2012 14:46:15, <[e-mail]> wrote:
>> Expanding short name to long name is expensive and using it frequently causes big performance difference between Windows and Unix. I think this change in 'require' and 'load' will be useful for most Windows users since not a few Windows users complain about slowness.
>
> The Primary Principle: Security is not exchangeable for performance.
>
> the secondary principle: but if the software is not usable by low
> performance, security looses its meaning.
>

I agree with you, trading security over performance or viceversa is not good.

>
> If the performance problem is in 'require' and 'load', change only them
> and be stayed File.expand_path the same behavior.
> Can't do so?
>

Problem is expand_path is used all over the place:

load.c:
rb_get_expanded_load_path
rb_feature_provided
rb_feature_p

file.c:
rb_file_absolute_path
rb_file_identical_p
rb_file_s_absolute_path
rb_find_file_ext_safe
rb_find_file_safe

ruby.c:
expand_include_path

Changing all those places seems more complex than just changing WEBrick.

Perhaps we can make File.realpath solve that for us, after all,
realpath is supposed to resolve symlinks and perhaps could be used to
expand shortnames into longnames.

From my point of view: core security is important, so is performance.

WEBrick is stdlib, not core, changes to make stdlib happy should not
compromise core security or performance.

If shortnames (outside web) was considered a security issue for core
then I would agree that expanding shortnames needs to be in core.

I can start working on making realpath use newer Windows API (instead
of stat) to obtain the expanded filename. Perhaps that will be a nice
alternative for WEBrick.

-- 
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駻y