nmh-workers
[Top] [All Lists]

Default file processing for refile -- mv or ln?

2020-05-08 07:38:34
Hello,

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.

Note:  I have no entry for refile(1mh) in my .mh_profile file.
Nor do I specify any switches on the command line, or use a
script or alias that supplies it (so far as I know).

There are certain messages that I refile directly from my inbox
to a save-folder.  I usually do something like this:

     $ scan +inbox
     [... output elided ...]
     $ show 5
     [... output elided ...]
     $ refile +SaveFolder

But:

     $ ls -i Mail/inbox/,5
     12345678 Mail/inbox/,5
     $ ls -i Mail/SaveFolder/* | tail
     12345678 Mail/SaveFolder/25

     $ find Mail/SaveFolder/25 -type f -printf '%n %i %p\n'
     2 12345678 Mail/SaveFolder/25

I also sometimes provide the message numbers -- e.g.

     $ refile +SaveFolder 5 6 7

but that doesn't seem to make a difference.

It seems that the default -- -nolink/mv(1) -- is performed the
vast majority of the time.  But about 5% of the time the other
operation -- -link/ln(1) -- is performed.  The first message file
that this happened to is dated 2014 May 26, though my save-folder
has message files dating to a year before that.  The latest file
is from last night.  I don't see any pattern in the files (like
maybe this happens only on Thursday nights).

I did not do anything special to my system on 2014 May 26.  (Or
yesterday.)  In fact, there are messages that I refiled earlier
on May 26 and on May 27 that were not ln(1)-ed.

Note:  I tried adding the following to my .mh_profile, to force
the -nolink operation:

     refile: -nolink

Initially, that seemed to solve the problem.  However, an hour
later, even _with_ that entry in the .mh_profile file, the
-link/ln(1) procedure occurred again.  B-(

I would greatly appreciate any suggestions as to what I might
fix, or at least investigate.

Thanks you!

                                Bob

P.S.  this is not a big deal, as I can just periodically run the
find(1) command on my save-folder to find all inodes with more
than 1 hard link, and then delete the unneeded path.  But of
course I'd rather not need to do that.

<Prev in Thread] Current Thread [Next in Thread>