Re: Better realpath

[Eli Zaretskii <eliz@gnu.org>]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Thu, 19 Jun 2008 10:06:42 +0400
> Cc: gdb-patches@sources.redhat.com
> 
> > I don't think such radical measures would be necessary.  We could
> > either (a) use canonicalize_filename, which doesn't check for
> > existence, 
> 
> Hmm, the documentation at
> 
> 	http://www.gnu.org/software/libc/manual/html_mono/libc.html
> 
> say:
> 
>     Function: char * canonicalize_file_name (const char *name)
> 	
> 	If any of the path components is missing the function returns a NULL pointer. 

My version of libc.info says something different:

     In any of the path components except the last one is missing the
     function returns a NULL pointer.

The "except the last" part makes all the difference.

I guess we need to try this to see which one is true.

> > or (2) use realpath on the argument's leading directories 
> > (i.e. call `dirname' to remove the last portion of the file name).  Am
> > I missing something?
> 
> And this will check dirname existance? This semantics is mid-way between checking
> everything for existance, and not checking anything. Is this really intuitive and
> desirable?

I was aiming for consistency with canonicalize_file_name, assuming it
behaves like my reference above says.

> > > Second is down-casing. If we don't want brute down-casing, and we want truly canonic
> > > names of paths, then "C:/documents and settings" should become "C:/Documents and Settings",
> > > and that requires actually poking at the file system to see what exact spelling is stored. 
> > 
> > No, that's not necessary either.  All you need is run the result of
> > GetFullPathName through GetLongPathName: if it fails, it means the
> > file does not exist, and you need to return it in whatever letter-case
> > it was passed to us; if it succeeds, it will return the file name as
> > it's recorded in the filesystem.  
> 
> That does not contradict what I say -- it *does* require poking at the file system,

Well, _any_ file-related system call eventually pokes the file system.
What I meant is that we don't need to do that yourself in application
code.

> ... what will be the return value of GetLongPathName on "C:/DOCUME~1/nonexistent/nonexistent2"
> and "C:/documents and settings/nonexistent/nonexistent2". Presumably, GetLongPathName will
> fail in both cases, and GDB will think those paths are unequal.

That's true, but it's no worse than today: FILENAME_CMP does not
handle comparison of short 8+3 aliases with their long variants.  So
we don't need to do this if we don't want to.  If we do want to handle
these cases, I guess we could iteratively chop directories from the
right and run them through GetLongPathName until we get to one that
does exist.  But I don't know if this is worth the hassle.  After all,
in the context of GDB, a file name recorded in the debug info could
well cease to exist by the time GDB tries to canonicalize its name.

> GetLongPathName, also, is not available on Windows 95. Is that an issue?

I don't think so.

> 2. Make lrealpath check for dirname existance only. The filename part will have to
> be downcased on Windows.

It doesn't need to be downcased: FILENAME_CMP copes with letter-case
differences.

> Now, which of those approaches you:
> 
>  - Will be willing to accept?

Any one of them, actually.

>  - Will be willing to hack on, and push in libibery?

"Willing", yes; "have time to", probably no.