Re: race condition? -or- better way to transparently edit a message's headers?
On 8/8/06, Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> wrote:
On 2006-08-08 11:56:07 -0500, mike wrote:
> these macros will eat the message and increment or decrement
> the numerical value on the right hand side of the
> X-Mutt-Importance header, not exceeding the inclusive range
> of 0-3. the only problem is that it doesn't work
> consistently (ie, the message is unmodified). if i hold
> down the left arrow, it will show a few modified messages
> (deleted+new). if i insert a sleep(1) call into the
> beginning of the script used as the editor, it works
> consistently. if i insert a sleep(1) call into the end of
> the script used as the editor, it does not work
> consistently. thoughts?
There's an mtime-based heuristic to diagnose unchanged
messages. Hence, the initial sleep(1) helps.
We could remove that heuristic, since it's really problematic
for any automated editing.
no need. i have modified my script to explicitly set the mtime to 1s
in the future. thank you for the quick and informative reply.
> on a related note, for my purposes in implementing such a
> system soley via macros, the editing system is lacking in
> flexibility. the editing of headers by a script should not
> induce this deleted+new behavior, as i want the operation to
> be as transparent as possible. i don't require the
> rudimentary revision control. i have hacked around this by
> explicitly calling sync-mailbox, next-undeleted, toggle-new,
> previous-undeleted; however, this is suboptimal -- i don't
> want to explicitly sync the the entire mailbox just to flag
> a message with a number.
Well, the deleted + new behavior basically has the reason that
we can safely add messages to folders, and internally mark
messages as deleted. Given that mutt doesn't lock mail folders
all the time, though, it's problematic with some folder formats
to simply delete old messages, or rewrite folders -- there
might have been an uncaught modification to the folder in the
mean time.
i'm not quite sure i'm following you. i gather that a modified
message is not reflected in the folder until sync-mailbox occurs.
such behavior makes perfect sense to me. i was under a general belief
that once $editor was invoked, i was editing the message as it
existed.
can you think of any way i might be able to get around it? mutt
passes a temporary file name to the editor that does not correlate to
the file name as it exists inside maildir. i *might* be able to
coerce the file name from procmail and insert an appropriate header
into the message; however, such a method would cease to function the
moment the message was relocated from its originating folder.
are there any variables within scope that i might be able to use to
determine the exact path to the selected message?
-mike