Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Message-ID: <4182983A.5070202@x-ray.at>
Date: Fri, 29 Oct 2004 21:21:30 +0200
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: coreutils rm nul
References: <41827684 DOT 7040007 AT x-ray DOT at> <20041029172609 DOT GC5890 AT trixie DOT casa DOT cgf DOT cx> <41828674 DOT 6090507 AT x-ray DOT at> <20041029183414 DOT GD7719 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20041029183414.GD7719@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Christopher Faylor schrieb:
> On Fri, Oct 29, 2004 at 08:05:40PM +0200, Reini Urban wrote:
>>Christopher Faylor schrieb:
>>>On Fri, Oct 29, 2004 at 06:57:40PM +0200, Reini Urban wrote:
>>>
>>>>Would it be appreciated if coreutils rm would be able to
>>>>remove special windows files, like nul, aux, com and such, if it's 
>>>>really a file and no device?
>>>>
>>>>I'm working on such a coreutils patch for rm(1) only, not mv(1), ln(1) 
>>>>or unlink(3) from cygwin1.dll.
>>>>Should it go to unlink(3) instead?
>>>>
>>>>If the original proposer of the coreutils package, Mark, will not revive 
>>>>in the next months I might be persuaded to maintain it then.
>>>
>>>Given the number of times I've mentioned the fact that we need coreutils
>>>with no response, I think it is safe to assume that it is still
>>>unmaintained.
>>>
>>>Unless there are objections in the next several hours this package is
>>>yours.
>>
>>The problem is if I really want to maintain such a beast.
>>Having maintained a patched sh-utils at my company (restricted 
>>password-less su and sudo extensions, centralized logging) I know what 
>>will happen...
>>
>>
>>>FWIW, I think that fixing unlink so that it can remove these kinds of
>>>files makes more sense than patching coreutils.  But, here again, Red
>>>Hat would probably need an assignment from you for this type of work.
>>
>>unlink nul: since only/mostly coreutils (echo > nul) create such files, 
>>I thought is better to safe some cycles in cygwin1.dll for every unlink 
>>call - it's far too slow anyway, but that's not our fault.
> 
> 
> Cygwin no longer creates files named "nul".  But, it wouldn't be coreutils
> creating the nul file in the above scenario anyway.  "echo" is normally
> a shell builtin:
> 
>   % type -f echo
>   echo is a shell builtin
> 
> and it was still the cygwin DLL creating the nul file when this happened a
> couple of months ago whether or not you're using echo or /bin/echo.

ok.

> If it was implemented in unlink it should be in a failure case as in:
> 
>   delete file
>     still exist?
>       no
> 	all done
>       yes
> 	is it a special file and actually on the disk?
> 	  yes
> 	    try harder

Sure, but you forgot the tricky ERROR_SHARING_VIOLATION => append to 
queue part.
   also locking, DELETE_ON_CLOSE, remote shares, ...
And the win95 section which I don't understand and cannot test so far. 
(no space left on device for another vmware)

For the beginning this section could go logically after the err: label.

   if (lasterr != ERROR_SHARING_VIOLATION)
     goto err;

   ...
   err:
   // now try real hard with the "\\?\" prefix. could be a special
   // filename or some unicode (without any \0 hopefully)

but this begins to look like unmaintainable spaghetti. anybody who is 
able to understand this should fix it then, once it is stable in rm(1).

> rather than
> 
>   is it a special file and actually on the disk?
>     no
>       do a normal unlink
>     yes
>       try real hard right now
> 
> This would minimize any slowdown in unlink.
> 
> Of course the unlink code is already a tangled mess now thanks to the
> attempts to accommodate the 'remove while the file is still open'
> operation so maybe it's best not to bother at all.  We might end up
> destabilizing unlink for the next three revisions.

Agreed. "delete on close" and the pending delqueue is only something for 
Pierre. That's why I thought at first go the easy way with this problem.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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