Skip site navigation (1) Skip section navigation (2)

Re: is_absolute_path incorrect on Windows

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: is_absolute_path incorrect on Windows
Date: 2011-02-03 16:50:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> > However, it misses the case with for example E:foo, which is a perfectly
> > valid path on windows. Which isn't absolute *or* relative - it's relative
> > to the current directory on the E: drive. Which will be the same as the
> > current directory for the process *if* the process current directory is
> > on drive E:. In other cases, it's a different directory.
> I would argue that E:foo is always relative (which matches
> is_absolute_path()).  If E: is the current drive of the process, it is
> relative, and if the current drive is not E:, it is relative to the last
> current drive on E: for that process, or the top level if there was no
> current drive.  (Tested on XP.)
> There seem to be three states:
> 	1. absolute - already tested by is_absolute_path()
> 	2. relative to the current directory (current drive)
> 	3. relative on a different drive
> We could probably develop code to test all three, but keep in mind that
> the path itself can't distinguish between 2 and 3, and while you can
> test the current drive, if the current drive changes, a 2 could become a
> 3, and via versa.

I have reviewed is_absolute_path() and have implemented
path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
Win32;  patch attached.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

Attachment: /rtmp/relative.diff
Description: text/x-diff (5.9 KB)

In response to


pgsql-hackers by date

Next:From: David E. WheelerDate: 2011-02-03 16:52:50
Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:From: Mladen GogalaDate: 2011-02-03 16:38:14
Subject: Re: [HACKERS] Slow count(*) again...

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group