make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in builtin function abspath


From: Eli Zaretskii
Subject: Re: Bug in builtin function abspath
Date: Thu, 01 Jun 2006 20:09:31 +0300

> Date: Thu, 01 Jun 2006 16:02:22 +0200
> From: Alessandro Vesely <address@hidden>
> 
> _fullpath is a wrapper around GetFullPathName: it possibly allocates
> the buffer and maps errors to errno. Since _fullpath is not in OS/2
> either, I'd use GetFullPathName directly.

I'd like to avoid too many Windows-specific APIs as much as possible.
There's no need to use _fullpath or GetFullPathName, as of now; the
patch I suggested works on Windows without any direct Win32 calls.
The questions I asked about _getdcwd was about OS/2, not Windows, and
they are only relevant if we decide that "d:./foo" is not the right
value abspath should return for d:foo arguments.

> I have some notes/questions about abspath in general and in win32:
> 
> - abspath does not follow symlinks, thus it does the wrong thing
> whith, e.g., ./symlink/../not_in_cwd.

What symlinks?  Windows doesn't have symlinks (unless you are talking
about .lnk shortcuts, which are not really symlinks and don't behave
like ones in many Win32 API functions).

Also, abspath is _documented_ to not follow links.  That's what
realpath is for.

> - Windows does not have the equivalent of realpath.

If we want realpath badly enough, we could lift the libgw32c emulation
of realpath.  But since there are no symlinks, I'm not sure we really
care.

> - GetFullPathName does not look at the disk but knows the current
> directory in each drive, much like make's abspath implementation.
> 
> - There is a GetLongPathName function that nicely recovers the
> real filename capitalization. It fails like realpath for missing
> components, but does not remove "." nor ".." and does not resolve
> NTFS' junctions (symbolic links). Furthermore, GetLongPathName
> is missing from older include files and may require NewAPIs.h
> 
> - There is also a GetShortPathName that retrieves the 8.3 form
> of existing files. Even if it requires that directories exist,
> its usage does make sense, because it is quite common that full
> paths contain spaces in Windows.

I know about these APIs, but don't think we should use it in this
context.  If you mentioned them because you think they should be used
in abspath, please explain why.

> One possibility to cope with the above would use a new function
> to determine the last directory component that already exists
> and is either out of starting_directory or on a different drive.
> Next we apply realpath (on Unix) or GetShortPathName (on Windows)
> to the first part of the path and then add further components in
> the same way abspath currently does it.

Sorry, I don't understand what problem are you trying to solve here.
Please explain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]