Re: scheduler: unlink... No such file or directory

[Matti Aarnio <mea@nic.funet.fi>]

On Wed, Aug 09, 2000 at 10:49:57PM +0400, Eugene Crosser wrote:
> While evaluating new x86 rackmount boxes I installed Zmailer on one
> (running Solars7 x86) and piped full mail feed there.  There are
> still things that I reported before but diagniostics is somewhat
> different:
> 
> scheduler: unlink(../queue/F/wV DDST)[sch-unctl-2]: No such file or directory
> scheduler: unlink(../queue/V/X?DDST)[sch-unctl-2]: No such file or directory

  These are - shall we say - absolute nonsense.

  At  scheduler/update.c: unctlfile() function:

	  if (cfp->dirind > 0)
	    sprintf(path, "../%s/%s/%s",
		    QUEUEDIR, cfpdirname(cfp->dirind), cfp->mid);
	  else
	    sprintf(path, "../%s/%s",
		    QUEUEDIR, cfp->mid);

	  eunlink(path,"sch-unctl-2");

  With  lib/esyslib.c: eunlink()  reporting the 'tag' value in
  sensible way (that is, a valid tag) I am inclined to consider
  that the  esyslib.c  and  update.c  were both compiled before
  linkage.  Therefore the  eunlink()  was corrent binary and
  produced correct result, but the 'path' content is there bogus.

  Bogus 'path' means that  cfp->mid  pointed string is bogus.

  Also, the  eunlink()  is called only if  'no_unlink' is
  zero, which means at one place at  scheduler/scheduler.c,
  and one place at  scheduler/update.c: unctlfile().  Just which...

  At update.c the  unctlfile() is called twice from  update.c: deletemsg()
  (highly unlikely), and once from  vtxupdate(), which means updates from
  any and all message statuses.

  All paths that I seem to be able to pick do feel to be ok.
  As if the message file has corrupted  without a valid "MID" value.

  On the other hand, a NULL pointer referral of  cfp->mid  should cause
  a crash when printing that 'path' content...

> Eugene

-- 
/Matti Aarnio	<mea@nic.funet.fi>