X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <478FA34C.2070008@stats.uwo.ca>
Date: Thu, 17 Jan 2008 13:49:48 -0500
From: Duncan Murdoch <murdoch AT stats DOT uwo DOT ca>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: rm fails with bad mount information
References: <478F769C DOT 8070501 AT stats DOT uwo DOT ca> <20080117155917 DOT GB13657 AT calimero DOT vinschen DOT de>
In-Reply-To: <20080117155917.GB13657@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 1/17/2008 10:59 AM, Corinna Vinschen wrote:
> On Jan 17 10:39, Duncan Murdoch wrote:
>> I'm a Windows maintainer for the R project.  We include the Cygwin rm.exe 
>> program in the toolset we've put together for developers, and have 
>> occasionally heard that it fails.
>>
>> A few days ago I tracked down the cause of failure to the following:
>>
>> Users who install Cygwin then uninstall it (perhaps improperly, I'm not 
>> sure) can be left with the registry key
>>
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/]
>>
>> set with a non-existent path as the "native" string value (which is 
>> normally be something like "c:\\cygwin").  When that happens, "rm -rf 
>> subdir" fails with this message:
>>
>> C:\temp  rm -rf test
>> rm: failed to get attributes of `/': No such file or directory
>>
>> I suspect this is user error in uninstalling Cygwin improperly, but it's 
>> still somewhat perplexing to users.  Perhaps rm (and other utilities doing 
>> whatever it is doing) should be more robust against bad mounts?
> 
> This is not a problem of rm.  It doesn't actually look for mount points.
> It just uses the POSIX paths it gets from the Cygwin DLL and the Cygwin
> DLL translates that into native paths using the mount points in the
> registry.
> 
> However, if the Cygwin installation has been uninstalled, how is rm
> supposed to find the Cygwin DLL?  It can't work.  You should really tell
> your users not to deinstall Cygwin when using your product.  It also
> doesn't make sense also to ship rm with your toolset.   Better rely on a
> functional Cygwin installation instead.  rm is part of coreutils which
> is installed by default anyway.

Our users don't install all of Cygwin, we've extracted the minimal parts 
needed for a build of R.  (We've also modified make and tar for our 
needs -- the originals require a full Cygwin setup, ours don't.)  So rm 
finds the Cygwin dll using the usual Windows rules for finding a DLL.

Yes, this sometimes causes trouble for users who already have Cygwin 
installed (a little bit of DLL hell), but we would rather have control 
over the versions of the tools in use.  Our experience is that most 
users who have Cygwin can easily deal with those problems (they don't 
install our copy of the DLLs), whereas users who don't have Cygwin have 
an easier time with just one install (our toolset) rather than 4 (our 
tools, Cygwin, Perl, MinGW).

I can understand you might not want to support the way we are using rm, 
but thought it was better to put the bug report in than to sit on it.

Duncan Murdoch


--
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/