On Thu, 8 Jul 1999 13:07:47 -0400, "D. Hammond"
<deh(_at_)crisp(_dot_)openix(_dot_)com>
wrote:
/bin/mail through telnet on NT keeps crashing, and when this has
(No duplicates, fortunately.)
4. Meanwhile, any mail that arrived while this was happening is lost
forever. (Correct?)
<...>
The last point can easily be remedied by renaming the file at some
point before the ftp executes, so you ftp over a datestamped copy, and
any mail which arrived between the time the spool file was renamed and
it was ftp:ed over is simply left until tomorrow (or whenever your
cron job executes next).
(So procmail would still save to "file" and if it's empty, create a
new one. Meanwhile, "file" occasionally gets renamed to "file-990708"
[for today's file] and ftp only attempts to fetch a file named this
way.)
That's a good idea. Thanks. So I could send another message from
home before getting the remote file, triggering the name change in
another procmail recipe. I think I can handle that. But it raises
a couple more questions. The remote_file should be locked, right?
Can it be done at the start of the recipe like ':0:'? If so, does
this recipe and all others that touch that file need to use the same
lockfile name? Or do I have to execute 'lockfile file.lock; mv file;
rm -f file.lock' in the action line?
I believe moves should be atomic. If anything is writing to the file
while it's being moved, the process that does the writing will be
referring to the file by file descriptor, not by name, so the write
should finish just fine. In other words, I don't think you even need
to bother with locking around the mv. (But it also shouldn't hurt.
I guess.)
And I would perhaps not worry about sending two messages, if you can
be reasonably sure the clocks of the two machines stay more or less
synchronized. The move could be done by the ISP's cron a few minutes
before the cron job at home is scheduled.
If you decide you do want to trigger the renaming from procmail, you
should perhaps use Procmail's built-in locking rather than rely on
lockfile(1):
:0i:file.lock # c flag if you also want to keep the trigger message
| mv -f file `date +file.%Y%M%D`
Or perhaps file should be catted to the end of `date +file.%Y%M%D` in
case it already exists, but I take it that is an even less likely
error condition.
Hope this helps,
Still do,
/* era */
--
.obBotBait: It shouldn't even matter whether <http://www.iki.fi/era/>
I am a resident of the state of Washington. <http://members.xoom.com/procmail/>
* Sign the European spam petition! <http://www.politik-digital.de/spam/en/> *