repeating delivery

I have a user (not onsite very much) that has a rule to forward
everything received (emails, appts, etc) to his personal email.

This has worked fine for a long time, but twice in the last 4 days
there has been an appt to him that does not get deleted in the gwia
send folder, which then causes him to receive another of the same appt
every time the gwia cycles through its folders looking for email to
send/receive.

Running gw2014sp2 on sles11sp4 / oes11sp3. Only seems to be happening
to his account, any ideas?

--
Stevo

Tags:

Parents
  • Am 10.01.2017 um 19:33 schrieb Stevo:
    > I have a user (not onsite very much) that has a rule to forward
    > everything received (emails, appts, etc) to his personal email.
    >
    > This has worked fine for a long time, but twice in the last 4 days
    > there has been an appt to him that does not get deleted in the gwia
    > send folder, which then causes him to receive another of the same appt
    > every time the gwia cycles through its folders looking for email to
    > send/receive.
    >
    > Running gw2014sp2 on sles11sp4 / oes11sp3. Only seems to be happening
    > to his account, any ideas?
    >

    Gwia knows nothing about accounts, so it's unlikely it's truly his
    account that is causing it. Is there AV scanner running on that server?
    The first idea is that something external is stopping the GWIA from
    deleting the file (if it's really the same file, and not a new copy)

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Massimo Rosen sounds like they 'said':

    > Gwia knows nothing about accounts, so it's unlikely it's truly his
    > account that is causing it. Is there AV scanner running on that
    > server? The first idea is that something external is stopping the
    > GWIA from deleting the file (if it's really the same file, and not a
    > new copy)
    >
    > CU,


    So my response to Massimo's comment is...

    There is a/v running on my gwia box, however it does not scan the mail
    volume where the gwia runs.

    As far as I can tell, it's the same file. At least it was the last two
    times this happened, as the modified date/time on the file stuck in the
    SEND folder was from the evening before.

    --
    Stevo
  • In article <1iedA.6$gV6.1@novprvlin0913.provo.novell.com>, Stevo wrote:
    > As far as I can tell, it's the same file. At least it was the last two
    > times this happened, as the modified date/time on the file stuck in the
    > SEND folder was from the evening before.


    Since there isn't a point in having it there, have you removed that file
    from the SEND folder?
    You can use a text view to see the header info to confirm that it is the
    same message.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Hi.

    Am 11.01.2017 um 00:40 schrieb Stevo:
    > Massimo Rosen sounds like they 'said':
    >
    >> Gwia knows nothing about accounts, so it's unlikely it's truly his
    >> account that is causing it. Is there AV scanner running on that
    >> server? The first idea is that something external is stopping the
    >> GWIA from deleting the file (if it's really the same file, and not a
    >> new copy)
    >>
    >> CU,

    >
    > So my response to Massimo's comment is...
    >
    > There is a/v running on my gwia box, however it does not scan the mail
    > volume where the gwia runs.
    >
    > As far as I can tell, it's the same file. At least it was the last two
    > times this happened, as the modified date/time on the file stuck in the
    > SEND folder was from the evening before.
    >


    Well, in that case the first would be to use lsof to check if and what
    holds the file open. And of course try Andy's suggestion to just delete
    the file (which should fail too if it's truly held open). If that works,
    I'd check for rights or filesystem issues.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Massimo Rosen sounds like they 'said':

    > Well, in that case the first would be to use lsof to check if and
    > what holds the file open. And of course try Andy's suggestion to just
    > delete the file (which should fail too if it's truly held open). If
    > that works, I'd check for rights or filesystem issues.
    >
    > CU,


    So my response to Massimo's comment is...

    Apparently there was nothing with any type of lock on it as I was able
    to delete the file each time, which then stopped the constant flow of
    appointments to this user's mailbox.

    --
    Stevo
  • Am 11.01.2017 um 17:59 schrieb Stevo:
    > Massimo Rosen sounds like they 'said':
    >
    >> Well, in that case the first would be to use lsof to check if and
    >> what holds the file open. And of course try Andy's suggestion to just
    >> delete the file (which should fail too if it's truly held open). If
    >> that works, I'd check for rights or filesystem issues.
    >>
    >> CU,

    >
    > So my response to Massimo's comment is...
    >
    > Apparently there was nothing with any type of lock on it as I was able
    > to delete the file each time, which then stopped the constant flow of
    > appointments to this user's mailbox.
    >

    That's pretty weird actually. ALl I can suggest here is a SR.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
Reply
  • Am 11.01.2017 um 17:59 schrieb Stevo:
    > Massimo Rosen sounds like they 'said':
    >
    >> Well, in that case the first would be to use lsof to check if and
    >> what holds the file open. And of course try Andy's suggestion to just
    >> delete the file (which should fail too if it's truly held open). If
    >> that works, I'd check for rights or filesystem issues.
    >>
    >> CU,

    >
    > So my response to Massimo's comment is...
    >
    > Apparently there was nothing with any type of lock on it as I was able
    > to delete the file each time, which then stopped the constant flow of
    > appointments to this user's mailbox.
    >

    That's pretty weird actually. ALl I can suggest here is a SR.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
Children
No Data