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

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

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

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.

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

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

Unsubscribe info:
Problem reports:

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