This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: coreutils rm nul

On Fri, Oct 29, 2004 at 09:21:30PM +0200, Reini Urban wrote:
>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
>>>>Unless there are objections in the next several hours this package is
>>>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.
>>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.

As I said:
"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."

I was pretty obviously not going to write a 47 line pseudo code example
of how you could do this, complete with all of the accommodations that
are in unlink()?  If I was going to do that, I would have written this

I was illustrating how it should be done to minimize the speed impact.
I wasn't writing the code for you.

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

Corinna, Pierre, I, and others have all worked on that code.

Anyway, in general, I tend to favor the correct way over the easy way.
So, if you are asking for my opinion, then, IMO, the "easy way" of
modifying coreutils is wrong and not worth the effort given the fact
that it is difficult to create these files at all.

I'm really not interested in debating this, though.  I don't want to do
a code review of unlink with you so if you want to maintain coreutils
and you think it's worth your time to support a special version of
coreutils with this in it, then have fun.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]