Re: desired bahavior for "email" interactivity?

Nathan,

The patch looks good, I did some test and it behave asexpected.
I committed the patch

Jean-Louis

On 26/03/17 04:51 PM, Nathan Stratton Treadway wrote:
> On Fri, Mar 17, 2017 at 15:51:41 -0400, Jean-Louis Martineau wrote:
>> On 17/03/17 08:45 AM, Nathan Stratton Treadway wrote:
>>> So, I guess the question is what's the desired behavior here?
>>>
>>> Off hand, I think I would expect  1) Amanda would send email every
>>> resend-delay seconds as long as it is waiting (for whatever reason), and
>>> 2) Amanda should always wait for input_file to change in some way from
>>> its initial state, but it shouldn't matter if that change is "creation"
>>> or "modification".
>> That's what I expect.
> Okay, great.
>
> Attached is a proof-of-concept patch to implement that behavior.
>
> As suggested in my earlier email, with this patch the program now saves
> an initial timestamp when it is first called and then waits for the file
> to be updated (i.e. either created or modified) before attempting to
> read it.
>
> Also, to avoid race conditions between the send_email and check_file
> functions, I moved all the logic to check the file type and permissions
> into the check_file function (which then, if necessary, saves the text
> of a warning message that will get included in the email generated by
> the send_email function).
>
> There are still situations where a change to the check-file file may
> result in two emails being generated the same second, one describing the
> state that existed before the change and one describing the new state.
> Presumably those situations won't occur too often in real-world usage,
> but to help the user understand that the two emails are actually
> different, the patch adds a line to the email showing information
> about the current state of the check-file. (In my testing, that
> information seemed useful even when there weren't double messages, since
> it made it clear what Amanda waiting for at each point in time...)
>
> (The patch also adds the changer name to the subject line of the
> generated email, since that seems useful to have menttioned, especially
> at sites with more than one changer in use.)
>
> I've attempted to follow the existing Perl style in the new code, but
> certainly would be interested in feedback on the Perl coding from any
> Perl gurus out there.
>
> Comments on "end-user" usability from anyone who's actually experienced
> the email interactivity in production would also be interesting...
>
> 							Nathan
> ----------------------------------------------------------------------------
> Nathan Stratton Treadway  -  [email protected]  -  Mid-Atlantic region
> Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
>   GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
>   Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239
This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail