Re: Default file processing for refile -- mv or ln?

[Bob Carragher]

Hi guys,

Sorry to take so long to follow up on this!  Ralph:  thank you
very much for this explanation!  This clarified for me what was
going on with -link/-nolink/-unlink (and -nounlink).  And it was
as you wrote (and the man page describes).

I have a theory as to why it seemed like the default combination
of flags -- -nolink -nounlink -- seemed to be doing different
things, which I suspect folks on this mailing list probably
figured out long ago:  newer messages that I rmm(1)-ed overwrote
the refiled message's old inbox inode, thus removing that hard
link (and leaving only the link for the inode in the
refile-folder) ... but only sometimes.

So, for example, I would refile a message and see:

     $ refile +SaveFolder 5
     $ ls -i Mail/inbox/,5 Mail/SaveFolder/1
     12345 Mail/inbox/,5
     12345 Mail/SaveFolder/1
     $ 

And sometimes, inc(1) would recreate that same message number,
and rmm(1)-ing it would overwrite the existing inode:

     $ inc
     Incorporating new mail into inbox...
     
       5+ 20/05/08 Ralph Corderoy     Re: Default file processing for refile -- 
mv or ln?
     $ rmm 5
     $ ls -i Mail/inbox/,5 Mail/SaveFolder/1
     98765 Mail/inbox/,5
     12345 Mail/SaveFolder/1
     $ 

But because I don't "pack" my inbox, or auto-delete NMH-removed
files, some NMH-removed files (e.g. ",5") may never be
overwritten in this way.  Thus some NMH-removed files would still
be linked into refile(1) folder files, and others wouldn't -- and
so creating my confusion.

Again, thank you for your help!

                                Bob

On Fri, 08 May 2020 13:51:28 +0100 Ralph Corderoy <ralph@inputplus.co.uk> sez:

> Hi Bob,
>
> > What might make refile(1mh) apply the non-default ln(1) to
> > refiled message files -- as if the -link switch had been
> > specified -- instead of the default mv(1) -- as if -nolink had
> > been specified?  And only sometimes; not always.
>
> refile(1)'s -nolink doesn't stop link(2) being used IIRC.
> link() is always attempted, falling back on copying if source
> and destination folders are on different filesystems.
> strace(1) should confirm this.
>
> -link/-nolink alters whether the inode which is the source is
> left alone afterwards or removed.  And removing is the normal
> method of renaming or rmmproc.
>
> -unlink actually removes the source inode rather than ‘rmm’ it.
>
> Perhaps that will allow you to spot a pattern.
>
> -- 
> Cheers, Ralph.