Message-Id: <200005262251.SAA18601@delorie.com>
Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: "Parker, Ron" <rdparker AT butlermfg DOT com>
To: "'cygwin-developers AT sourceware DOT cygnus DOT com'"
	 <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Possible path processing change
Date: Fri, 26 May 2000 17:47:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

This originally started as an idea for fixing some of the differences
between how UNIX and cygwin handle paths.

Currently cygwin recognizes both /cygdrive/<drive-letter> and
//<drive-letter> as paths for unmounted drives.  Additionally it recognizes
//server/share as a UNC path.  This leads to two problems.  The first is
that //<drive-letter>/directory can be ambiguous.  The second is that
scripts and programs which build paths beginning with two slashes do not
resolve to absolute paths under cygwin as they do in UNIX.

This lead to a few ideas:
* Remove support for //<drive-letter>
* Replace //server/share with server:share
* Replace //*path with /path

This would get rid of the ambiguity of double-slashed paths and allow cygwin
to handle sloppy programs that try to access //path, ///path and similar
things.

Chris has already requested the //server/share stay in place because of a
number of scripts that he has.  Prior to his request I thought these changes
might speed up path conversion.  Now I am not sure.

Would any of these things be worth doing?

If there is no //server/share should we try parsing it as /directory/...?