flexfax: docq files not getting cleaned up (bug found)

[John Williams <williams@morinda.com>]

On Tue, 17 Aug 1999, Jay R. Ashworth wrote:
> On Mon, Aug 16, 1999 at 06:32:53PM -0600, John Williams wrote:
> > I have a problem with files staying around in the docq directory
> > forever after the job completes.
> > 
> > The reason they are staying around is that there is more than one link to
> > the file.  For example:
> >  799103 -rw-rw----  17 uucp     60002       30857 Dec  4  1998 doc16422.ps
> >  799103 -rw-rw----  17 uucp     60002       30857 Dec  4  1998 doc16422.ps.12852
> >  799103 -rw-rw----  17 uucp     60002       30857 Dec  4  1998 doc16422.ps.12853
> > [ 14 more hardlinks follow... ]
> > 
> > I can reproduce the problem by sending file to more than one destination.
> > i.e. more than one -d option in the sendfax command.  (We have a lot of
> > users who send jobs to multiple destinations.)
> 
> Check the archives; I'm fairly sure someone found and fixed this once
> before -- it's in the clean script, which apparently doesn't quite
> cooperate with the sendfax script on multiple destinations.

Actually, I did some more investigation last night, and found the problem.
When Hylafax is done with the job file, it renames it to the source file,
in the following routine from FaxRequest.c++:

/*
 * Check if a document that is about to be removed from
 * the job request was converted from another.  If so,
 * rename the source document according to convention
 * so that all references to the document point to the
 * same file when everything has been sent.  This has the
 * effect of decrementing the link count on the source
 * file and permits us to use the link count as a reference
 * use count for releasing imaged documents (see the
 * large comments explaining this in the scheduler).
 */
void
FaxRequest::renameSaved(u_int fi)
{
    if (fi > 0 && requests[fi-1].isSavedOp()) {
        faxRequest& src = requests[fi-1];
        fxStr basedoc = mkbasedoc(src.item);
        if (Sys::rename(src.item, basedoc) < 0) {
            logError("Unable to rename transmitted document %s: %s",
                (const char*) src.item, strerror(errno));
            Sys::unlink(src.item);      // just remove it (???XXX)
        }
        src.item = basedoc;             // change job reference
    }
}

But remember that the job file and the source file are actually hard
linked together.  The problem is that POSIX.1 says this:
"If the <old> argument and the <new> argument both refer to links to 
the same existing file, the rename() function shall return successfully 
and perform no other action."

So the rename() function is returning success but doing nothing. 
(I verified this on Linux and HPUX, and they both comply with posix.)

Since the backup plan is to unlink the file anyway, I think a good
strategy to deal with the posix behavior is to always do an unlink after
the rename.  If rename actually renames the file, the unlink will not have
anything to unlink, but that's ok.  If the rename succeeds but leaves the
file there, the unlink will remove the file, which is what we want.  And
if the rename fails, the behavior will be the same as it is now.

I will post a (tested) patch in a few days.

~ John Williams