Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 5 May 2005 12:49:00 -0400
From: Christopher Faylor <cgf-no-personal-reply-please@cygwin.com>
To: cygwin@cygwin.com
Cc: eggert@CS.UCLA.EDU
Subject: Re: mkdir -p and network drives
Message-ID: <20050505164900.GG5374@trixie.casa.cgf.cx>
Reply-To: cygwin@cygwin.com
References: <3.0.5.32.20050502232204.00b52180@incoming.verizon.net> <42777719.8090103@byu.net> <8764xym6vf.fsf@penguin.cs.ucla.edu> <427A147D.2030109@byu.net> <87acn9aavq.fsf@penguin.cs.ucla.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87acn9aavq.fsf@penguin.cs.ucla.edu>
User-Agent: Mutt/1.5.8i

On Thu, May 05, 2005 at 09:35:53AM -0700, Paul Eggert wrote:
>Eric Blake <ebb9@byu.net> writes:
>
>> //MACHINE currently generates ENOENT, whether or not there is a
>> server on the network with that name, and mkdir(2), stat(2), and
>> chdir(2) with an argument of "//MACHINE" fail.
>
>That's certainly a hassle.  Let's not worry about going through
>zillions of lines of application code working around that
>incompatibility.  Let's get Cygwin fixed instead.

Cygwin has had this (windows) limitation since 1997.  I don't think
anyone is in a hurry to fix it.  It isn't trivial to do.  The
main thing that seems to be affected is "mkdir -p" so if we just
have to keep a localized patch for mkdir sitting around it seems
like that is our best option.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/