• msged feature :(

    From Markus Reschke@2:240/1661 to All on Tuesday, May 05, 2015 20:40:44
    Hi!

    Have you ever used the "move message(s)" function to move a single or multiple messages from one area to another? This function has a nasty issue regarding message attributes, they are cleared and set new. When you move a netmail which
    is already sent to another netmail area, the netmail will have the sent attribute cleared and will be sent again. Bummer!

    For a proper patch I'd like to ask you about your opinion in which cases the sent flag should be kept when moving messages. Should it be kept in any case? Or just if the source and destination area types are the same, i.e. from a netmail area to another netmail area? Or do you got a better idea?

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Kai Richter@2:240/1351.7 to Markus Reschke on Tuesday, May 05, 2015 21:10:50
    Tach auch Markus!

    Am 05 May 15, Markus Reschke schrieb an All:

    Have you ever used the "move message(s)" function to move a single or multiple messages from one area to another? This function has a nasty issue regarding message attributes, they are cleared and set new.

    I noticed that because of your input to my netmail folder. ;-)

    When you move a netmail which is already sent to another netmail
    area, the netmail will have the sent attribute cleared and will be
    sent again. Bummer!

    got a better idea?

    Why do you want to move netmail to another area?
    In most cases it's for archiving, not for processing.

    So all archiv areas should have "LocalArea" as area definition.

    I'd like to call it a configuration error of your destination mail areas. ;-)


    Okok, now seriously. I think keeping flags as they are in any cases is the best
    solution. They were sent into the network already and if a resend in the destination area is wanted it could be done by the areafix rescan function.

    Tschuess

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Mod HWG:Fido. Strike! Fido scores. (2:240/1351.7)
  • From Torsten Bamberg@2:240/5832 to Markus Reschke on Wednesday, May 06, 2015 08:00:40
    Hallo Markus!

    Dienstag, den 05. Mai 2015 20:40, Markus Reschke schrieb an All:

    For a proper patch I'd like to ask you about your opinion in which cases the sent flag should be kept when moving messages. Should it be kept in any case? Or just if the source and destination area types are the same, i.e. from a netmail area to another netmail area? Or do you got a better idea?
    Probably you set 'sent' and 'local' for your special netmailfolders as default.

    Regards,
    Markus
    Bye/2 Torsten

    ... MAILBOX02: Up 29d 15h 47m (BTUp2V1.5)
    --- GoldED+/EMX 1.1.4.7
    * Origin: DatenBahn BBS (2:240/5832)
  • From Markus Reschke@2:240/1661 to Kai Richter on Wednesday, May 06, 2015 18:13:32
    Hi Kai!

    May 05 21:10 2015, Kai Richter wrote to Markus Reschke:

    I noticed that because of your input to my netmail folder. ;-)

    Yep, it's really annoying.

    Why do you want to move netmail to another area?
    In most cases it's for archiving, not for processing.

    I got several netmail areas for different tasks, like areamgr for example. I've
    also set up a bunch of filter rules to sort incoming netmail to specific areas (similar to what procmail does for email).

    So all archiv areas should have "LocalArea" as area definition.

    That would work for a archive type area.

    I'd like to call it a configuration error of your destination mail
    areas. ;-)

    Too simple ;) The current setup is intended.

    Okok, now seriously. I think keeping flags as they are in any cases
    is the best solution. They were sent into the network already and if
    a resend in the destination area is wanted it could be done by the areafix rescan function.

    I don't think that this would be a good idea when moving a message from a netmail area to an echomail area. The "crash" attribute wouldn't make much sense for an echomail. Therefor my idea was to keep the attributes when source and destination area are of the same type.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Markus Reschke@2:240/1661 to Torsten Bamberg on Wednesday, May 06, 2015 18:23:50
    Hello Torsten!

    May 06 08:00 2015, Torsten Bamberg wrote to Markus Reschke:

    For a proper patch I'd like to ask you about your opinion in which
    cases the sent flag should be kept when moving messages. Should it be
    kept in any case? Or just if the source and destination area types are
    the same, i.e. from a netmail area to another netmail area? Or do you
    got a better idea?

    Probably you set 'sent' and 'local' for your special netmailfolders
    as default.

    A default "sent" attribute would fix the issue, but only if the netmail is already sent. When it's not sent yet, it will get the sent attribute when moved
    and won't be sent anymore.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Alan Ianson@1:153/757 to Markus Reschke on Wednesday, May 06, 2015 10:30:58
    Hi Markus,

    For a proper patch I'd like to ask you about your opinion in which
    cases the sent flag should be kept when moving messages. Should it be kept in any case? Or just if the source and destination area types
    are the same, i.e. from a netmail area to another netmail area? Or do
    you got a better idea?

    I have not moved a netmail in eons but I would be very surprised that the attributes were changed, I think the attributes should be kept and they can be changed later if need be, or maybe an option to change the attribues on move but by default they shouldn't change.

    Ttyl :-),
    Al

    --- Msged/LNX 6.1.2
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Torsten Bamberg@2:240/5832 to Markus Reschke on Wednesday, May 06, 2015 23:11:21
    Hallo Markus!

    Mittwoch, den 06. Mai 2015 18:23, Markus Reschke schrieb an Torsten Bamberg:

    Probably you set 'sent' and 'local' for your special netmailfolders
    as default.
    A default "sent" attribute would fix the issue, but only if the netmail is already sent. When it's not sent yet, it will get the sent attribute when moved and won't be sent anymore.
    Well, another reason to port or code a netmailtracker, like itrack.
    ;-)

    Regards,
    Markus
    Bye/2 Torsten

    ... MAILBOX02: Up 30d 07h 30m (BTUp2V1.5)
    --- GoldED+/EMX 1.1.4.7
    * Origin: DatenBahn BBS (2:240/5832)
  • From Markus Reschke@2:240/1661 to Alan Ianson on Friday, May 08, 2015 15:13:08
    Hello Alan!

    May 06 10:30 2015, Alan Ianson wrote to Markus Reschke:

    I have not moved a netmail in eons but I would be very surprised that
    the attributes were changed, I think the attributes should be kept
    and they can be changed later if need be, or maybe an option to
    change the attribues on move but by default they shouldn't change.

    While moving a message msged clears all attributes, sets the area's default attributes configured (crash, priv, killsent, hold, direct) and sets local in any case. And I concur that the attributes should be kept if possible, i.e. if source and destination areas are of the same type. I've submitted a patch to Gerrit today. If source and destination area types match, no attributes are cleared. When they differ, attributes are cleared and set to the destination area's defaults, but the sent attribute is kept. I think this should be a sound
    compromise to prevent any resent messages.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Alan Ianson@1:153/757 to Markus Reschke on Friday, May 08, 2015 13:14:58
    Hello Markus,

    While moving a message msged clears all attributes, sets the area's default attributes configured (crash, priv, killsent, hold, direct)
    and sets local in any case. And I concur that the attributes should
    be kept if possible, i.e. if source and destination areas are of the
    same type. I've submitted a patch to Gerrit today. If source and destination area types match, no attributes are cleared. When they differ, attributes are cleared and set to the destination area's defaults, but the sent attribute is kept. I think this should be a
    sound compromise to prevent any resent messages.

    Sounds perfectly resonable, thanks Markus.

    Ttyl :-),
    Al

    --- Msged/LNX 6.1.2
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Benny Pedersen@2:230/0 to Markus Reschke on Sunday, May 10, 2015 01:38:26
    Hello Markus!

    05 May 2015 20:40, Markus Reschke wrote to All:

    Have you ever used the "move message(s)" function to move a single or multiple messages from one area to another? This function has a nasty issue regarding message attributes, they are cleared and set new. When you move a netmail which is already sent to another netmail area, the netmail will have the sent attribute cleared and will be sent again. Bummer!

    that was why Ward complained of 800+ netmail msgs from me :/

    For a proper patch I'd like to ask you about your opinion in which
    cases the sent flag should be kept when moving messages. Should it be kept in any case? Or just if the source and destination area types are the same, i.e. from a netmail area to another netmail area? Or do you
    got a better idea?

    is it just msged ?

    eg if golded is used is rest of husky ok ?

    still planning on make husky 1.9 stable, but i nearly lost track of problems to
    have it :(


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.18.11-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Benny Pedersen@2:230/0 to Kai Richter on Sunday, May 10, 2015 01:41:00
    Hello Kai!

    05 May 2015 21:10, Kai Richter wrote to Markus Reschke:

    Why do you want to move netmail to another area?

    rntrack is more usefull if its possible to move some netmails


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.18.11-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Benny Pedersen@2:230/0 to Markus Reschke on Sunday, May 10, 2015 01:43:50
    Hello Markus!

    06 May 2015 18:23, Markus Reschke wrote to Torsten Bamberg:

    A default "sent" attribute would fix the issue, but only if the
    netmail is already sent. When it's not sent yet, it will get the sent attribute when moved and won't be sent anymore.

    how to set this ?


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.18.11-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Torsten Bamberg@2:240/5832 to Benny Pedersen on Sunday, May 10, 2015 02:52:46
    Hallo Benny!

    Sonntag, den 10. Mai 2015 01:38, Benny Pedersen schrieb an Markus Reschke:

    Have you ever used the "move message(s)" function to move a single or
    multiple messages from one area to another? This function has a nasty
    issue regarding message attributes, they are cleared and set new. When
    you move a netmail which is already sent to another netmail area, the
    netmail will have the sent attribute cleared and will be sent again.
    Bummer!
    that was why Ward complained of 800+ netmail msgs from me :/
    Obviously isn't DBridge able to manage more than 1023 netmails at the inbound directory. :-(

    For a proper patch I'd like to ask you about your opinion in which
    cases the sent flag should be kept when moving messages. Should it be
    kept in any case? Or just if the source and destination area types are
    the same, i.e. from a netmail area to another netmail area? Or do you
    got a better idea?
    is it just msged ?
    Just MsgEd. Even MsgEd comming up the husky 1.9 portstree is insolved.

    eg if golded is used is rest of husky ok ?
    Afaik GoldEd is also insolved, because GoldEd strips all attributes as well.

    I haven't had any problems moving Netmails somewhere from or to my different netmails folder, because I'm using a proper netmail tracker.

    still planning on make husky 1.9 stable, but i nearly lost track of problems to have it :(
    Well, I've compiled husky1.9 on december last year. On and for BSD not Linux of
    course. But I wasn't able to compile fastlist. What sort of problems you've got
    to compile the 1.9 stable?

    Regards Benny

    * Origin: duggi.junc.org where qico is waiting (2:230/0)
    qico is waiting on 2:240/5835 :-)

    Bye/2 Torsten

    ... MAILBOX02: Up 00d 01h 45m (BTUp2V1.5)
    --- GoldED+/EMX 1.1.4.7
    * Origin: DatenBahn BBS (2:240/5832)
  • From Markus Reschke@2:240/1661 to Benny Pedersen on Sunday, May 10, 2015 10:03:36
    Hello Benny!

    May 10 01:38 2015, Benny Pedersen wrote to Markus Reschke:

    that was why Ward complained of 800+ netmail msgs from me :/

    :)

    is it just msged ?

    Yes, but there's a patch now ;)

    eg if golded is used is rest of husky ok ?

    Yes.

    still planning on make husky 1.9 stable, but i nearly lost track of problems to have it :(

    1.9 is strongly recommended. Be aware that the configuration has changed a little bit.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Markus Reschke@2:240/1661 to Benny Pedersen on Sunday, May 10, 2015 10:09:16
    Hello Benny!

    May 10 01:43 2015, Benny Pedersen wrote to Markus Reschke:

    A default "sent" attribute would fix the issue, but only if the
    netmail is already sent. When it's not sent yet, it will get the sent
    attribute when moved and won't be sent anymore.

    how to set this ?

    That's not supported by msged, but I've submitted a patch for that problem.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)
  • From Benny Pedersen@2:230/0 to Markus Reschke on Sunday, May 31, 2015 13:41:58
    Hello Markus!

    10 May 2015 10:03, Markus Reschke wrote to Benny Pedersen:

    that was why Ward complained of 800+ netmail msgs from me :/
    :)

    +1

    is it just msged ?
    Yes, but there's a patch now ;)

    +1

    eg if golded is used is rest of husky ok ?
    Yes.

    super, i had in plan b with crashmail/crashtick if its impossible with husky on
    gentoo :(

    still planning on make husky 1.9 stable, but i nearly lost track of
    problems to have it :(

    1.9 is strongly recommended. Be aware that the configuration has
    changed a little bit.

    hopefully docs are up2date, but yes still no stable gentoo ebuilds for stable husky 1.9 :(

    is config path respecting $HOME ?

    eq not using /etc/fidonet as config dir but keep in drop priveledged users homedir so one compiled husky works multiusers install :)

    if not yet i look forward to see it


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.18.12-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Markus Reschke@2:240/1661 to Benny Pedersen on Sunday, May 31, 2015 16:01:52
    Hi Benny!

    May 31 13:41 2015, Benny Pedersen wrote to Markus Reschke:

    is it just msged ?
    Yes, but there's a patch now ;)

    +1

    Hopefully Gerrit will commit the patch to the cvs soon.

    is config path respecting $HOME ?

    The directory for the common configuration is specified in the huskymak.cfg. msged supports a local cfg (.msged) in the home dir, IIRC.

    eq not using /etc/fidonet as config dir but keep in drop priveledged users homedir so one compiled husky works multiusers install :)

    There's a cfg option in msged to specify msg highwater counters for multiple users.

    if not yet i look forward to see it

    From my experience husky is not fully multi-user/parallel-application capable, i.e. several applications running on the msg base at the same time causes sometimes trouble. For example, msged has problems with the highwater marks when writing a new message and hpt tosses new echomail at the same time. I'm managing most automatic stuff with lock files to minimize the possibility of parallel processing. I think a fully multi-whatever capable msg base would require a major rewrite of smapi and its API, would have to become a daemon like a SQL database.

    Regards,
    Markus

    ---
    * Origin: *** theca tabellaria *** (2:240/1661)