From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24786 invoked by alias); 19 Jun 2008 06:07:12 -0000 Received: (qmail 24266 invoked by uid 22791); 19 Jun 2008 06:07:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Jun 2008 06:06:41 +0000 Received: (qmail 20190 invoked from network); 19 Jun 2008 06:06:39 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jun 2008 06:06:39 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: Better realpath Date: Thu, 19 Jun 2008 07:27:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806141024.41812.vladimir@codesourcery.com> <200806181133.11578.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200806191006.43356.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00348.txt.bz2 On Wednesday 18 June 2008 22:54:13 Eli Zaretskii wrote: > > The first question is about checking for file existance. Assuming we do= n't want > > this check, we basically get to rewrite gdb_realpath from scratch, maki= ng it > > operate on a purely syntactic basis. >=20 > I don't think such radical measures would be necessary. We could > either (a) use canonicalize_filename, which doesn't check for > existence,=20 Hmm, the documentation at http://www.gnu.org/software/libc/manual/html_mono/libc.html say: Function: char * canonicalize_file_name (const char *name) =09 If any of the path components is missing the function returns a NULL point= er.=20 .... Function: char * realpath (const char *restrict name, char *restrict re= solved) =20 A call to realpath where the resolved parameter is NULL behaves exactly li= ke=20 canonicalize_file_name. The function allocates a buffer for the file name = and=20 returns a pointer to it. If resolved is not NULL it points to a buffer int= o=20 which the result is copied. It is the callers responsibility to allocate a= =20 buffer which is large enough. On systems which define PATH_MAX this means= =20 the buffer must be large enough for a pathname of this size. For systems without limitations on the pathname length the requirement cannot be met and programs should not call realpath with anything but NULL for the=20 second parameter.=20 One other difference is that the buffer resolved (if nonzero) will contain= the=20 part of the path component which does not exist or is not readable if the= =20 function returns NULL and errno is set to EACCES or ENOENT.=20 >From that, I don't quite understand why you think canonicalize_file_name d= oes not check for file existance. Is documentation in error? > or (2) use realpath on the argument's leading directories=20 > (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 ch= ecking everything for existance, and not checking anything. Is this really intuiti= ve and desirable? > > 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:/Docu= ments and Settings", > > and that requires actually poking at the file system to see what exact = spelling is stored.=20 >=20 > 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.=20=20 That does not contradict what I say -- it *does* require poking at the file= system, so if some component of path is missing, you get no canonical representatio= n. The approach of returning paths that don't exist unmodified seem risky, in = particular... > For example, calling GetLongPathName=20 > with either "C:/documents and settings" or "C:/DOCUME~1" will return > "C:\Documents and Settings". ... what will be the return value of GetLongPathName on "C:/DOCUME~1/nonexi= stent/nonexistent2" and "C:/documents and settings/nonexistent/nonexistent2". Presumably, GetLo= ngPathName will fail in both cases, and GDB will think those paths are unequal. GetLongPathName, also, is not available on Windows 95. Is that an issue? > > So, the approaches are: > >=20 > > 1. Make lrealpath always check for file existance, and: > > - Either revise window case to get spelling from the filesystem, or > > - Add a flag "I don't care about case differences, don't downcase" > >=20 > > 2. Write another function that does purely syntactic normalization of p= aths. > > It will not change case of paths on windows, naturally. > >=20 > > Which of those approaches you: > >=20 > > - Will be willing to accept? > > - Will be willing to hack on? >=20 > I hope I answered those questions now. If not, please tell. No, I don't think I have found clear answers to either of those questions. = You comments suggested another approach, so here's the updated list of alternatives: 1. Make lrealpath always check for file existance. On Windows, make it use GetLongPathName, instead of lowercasing, to get canonical path name. 2. Make lrealpath check for dirname existance only. The filename part will = have to be downcased on Windows. 3. Implement syntax-only simplification function; it won't be able to use t= he exact spelling as stored in filesystem on Windows, and it won't be able to handle= short names. It appears to me that (1) is the easiest approach, minimally disturbing for existing code, and the one that I personally can implement and defend befor= e libibery maintainers. Now, which of those approaches you: - Will be willing to accept? - Will be willing to hack on, and push in libibery? - Volodya