[ruby-core:39456] Re: File.realpath behavior questions

Hello,

2011/9/11 Luis Lavena <[e-mail]>:
> Hello,
>
> Reading File.realpath documentation:
>
> /*
> =A0* call-seq:
> =A0* =A0 =A0 File.realpath(pathname [, dir_string]) =A0-> =A0real_pathnam=
e
> =A0*
> =A0* =A0Returns the real (absolute) pathname of _pathname_ in the actual
> =A0* =A0filesystem not containing symlinks or useless dots.
> =A0*
> =A0* =A0If _dir_string_ is given, it is used as a base directory
> =A0* =A0for interpreting relative pathname instead of the current directo=
ry.
> =A0*
> =A0* =A0All components of the pathname must exist when this method is
> =A0* =A0called.
> =A0*/
>
> And checking current behavior on Windows, every component of the path
> is check for existence, so:
>
> C:\Users\Luis>ruby -e "puts File.realpath('C:/foo')"
> -e:1:in `realpath': No such file or directory - C:/foo (Errno::ENOENT)
> =A0 =A0 =A0 =A0from -e:1:in `<main>'
>
> C:\Users\Luis>ruby -e "puts File.realpath('C:/foo/bar')"
> -e:1:in `realpath': No such file or directory - C:/foo (Errno::ENOENT)
> =A0 =A0 =A0 =A0from -e:1:in `<main>'
>
> Both trigger the same error, stating that C:/foo do not exist.

Yes, it's same with POSIX realpath() behavior. If I understand correctly,
windows libc don't have readpath function. therefore current behavior
is adjusted with unix platform.


> My question: can this behavior be changed for Windows?
>
> Asking this because we are not reading and resolving symlink,
> junctions or hardlinks in Ruby for Windows, so doing the entire
> traversal and check seems a bit expensive (several stat() calls)
>
> This means: build absolute path, expand if required, combine with
> GetFileAttributesEx to check for existance.
>
> Would this approach be acceptable?

I have no strong opinion. But I have a little curious. Why do you want
to avoid several stat()? unix platform also use such a bit expensive check
and now works.