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 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?
	all done
	is it a special file and actually on the disk?
	    try harder

rather than

  is it a special file and actually on the disk?
      do a normal unlink
      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.


Unsubscribe info:
Problem reports:

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