• exec/tickit.js

    From deuce@VERT to CVS commit on Monday, December 14, 2015 00:06:40
    exec tickit.js NONE 1.1
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv9510

    Added Files:
    tickit.js
    Log Message:
    Initial TIC handler in JavaScript.
    Currently just parses the TIC files, doesn't actually do anything.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Monday, December 14, 2015 00:20:02
    exec tickit.js 1.1 1.2
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv10032

    Modified Files:
    tickit.js
    Log Message:
    Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Monday, December 14, 2015 03:05:43
    exec tickit.js 1.2 1.3
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv14204

    Modified Files:
    tickit.js
    Log Message:
    Now works for me.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Monday, December 14, 2015 03:42:04
    exec tickit.js 1.3 1.4
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv17737

    Modified Files:
    tickit.js
    Log Message:
    Use -zd options for addfiles.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Accession@VERT/PHARCYDE to deuce on Monday, December 14, 2015 06:10:34
    Hello deuce,

    On 14 Dec 15 00:20, deuce wrote to CVS commit:

    exec tickit.js 1.1 1.2
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv10032

    Modified Files:
    tickit.js
    Log Message:
    Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

    Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From deuce@VERT to CVS commit on Monday, December 14, 2015 15:08:10
    exec tickit.js 1.4 1.5
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv31321

    Modified Files:
    tickit.js
    Log Message:
    Make the area translation less ugly in the announce message.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Deuce@VERT/SYNCNIX to Accession on Monday, December 14, 2015 15:00:21
    Re: Re: exec/tickit.js
    By: Accession to deuce on Mon Dec 14 2015 06:10 am

    Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

    Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

    I honestly have no idea. I found zero information about all the different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

    Where does the hub get the password it puts into the TIC files if not from the packet password?

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From deuce@VERT to CVS commit on Monday, December 14, 2015 15:31:48
    exec tickit.js 1.5 1.6
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv32080

    Modified Files:
    tickit.js
    Log Message:
    Fix wildcard search for nodes... was skipping replacing the last element
    with ALL.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Nicholas Boel@VERT to Deuce on Monday, December 14, 2015 21:44:16
    Hello Deuce,

    On 14 Dec 15 15:00, Deuce wrote to Accession:

    Shouldn't this be a new option field? If you don't have a PKTPWD
    set for echomail/netmail, you would still have to enable this,
    therefore enabling message packet passwords, in order to use TICs
    properly?

    I honestly have no idea. I found zero information about all the
    different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have
    their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

    Where does the hub get the password it puts into the TIC files if not
    from the packet password?

    In just about every software I've used so far, it is it's own entity, ie: "TICPWD" or "TIC password". As far as I've seen, message areas and file areas are completely separate from each other, and don't use the same passwords.

    If your uplink never asked you for a TIC password, then maybe he just made it the same as your packet password.

    For example, If I was to use all of the husky tools (ie: no Synchronet), I would use both HPT (for echomail and netmail) and HTICK (for files). There is separate config file options for pktpwd and ticpwd, which is why I was confused
    and asked you about it.

    It's possible they're one in the same in some of the older stuff.. IIRC, Allfix
    is also separate from anything echomail/netmail related, but I never used it so
    don't know specifics.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Deuce@VERT/SYNCNIX to Nicholas Boel on Monday, December 14, 2015 22:19:30
    Re: Re: exec/tickit.js
    By: Nicholas Boel to Deuce on Mon Dec 14 2015 09:44 pm

    In just about every software I've used so far, it is it's own entity, ie: "TICPWD" or "TIC password". As far as I've seen, message areas and file areas are completely separate from each other, and don't use the same passwords.

    Sure, it's technically possible to use different passwords for TIC than for binkp, areafix, packets, etc. A straw poll of sysops hasn't shown any of them having a different packet password than the TIC password.

    If someone actually has a config like that and can explain why, I'll consider it, but it would need the same wildcard ability as the PKTPWD lines in sbbsecho.cfg. All of these passwords (with the exception of the binkp one) basically do the same thing in the same way over the same link.

    If your uplink never asked you for a TIC password, then maybe he just made it the same as your packet password.

    I never selected a TICK password because I never wanted the files. Only reason I know what my TICK password is is because it's transferred in plain text in the TIC file.

    For example, If I was to use all of the husky tools (ie: no Synchronet), I would use both HPT (for echomail and netmail) and HTICK (for files). There is separate config file options for pktpwd and ticpwd, which is why I was confused and asked you about it.

    Sure, it's technically possible, but tickit.js is not intended to be a complete TICK solution. I'm not inclined to perpetuate needless complexity, so until there's a problem that needs solving, I'm not going to make the script more complex "Just In Case".

    It's possible they're one in the same in some of the older stuff.. IIRC, Allfix is also separate from anything echomail/netmail related, but I never used it so don't know specifics.

    That's the biggest problem I'm seeing with TICK stuff is that the majority of it is simply not documented. Some information can be gleaned from the various programs that do it, but not enough.

    I see no reason not to require that the packet password and TICK password for a link to be the same. If there is a reason, and someone explains it, I'll consider changing that requirement.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From deuce@VERT to CVS commit on Tuesday, December 15, 2015 15:29:08
    exec tickit.js 1.6 1.7
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv30741

    Modified Files:
    tickit.js
    Log Message:
    Remove the announce message generation. Synchronet has had a new file scan function for a very very long time now, we don't need to duplicate this functionality.

    (Unless I misunderstand what the announce message is for?)




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Accession@VERT/PHARCYDE to Deuce on Tuesday, December 15, 2015 17:25:20
    Hello Deuce,

    On 14 Dec 15 22:19, Deuce wrote to Nicholas Boel:

    In just about every software I've used so far, it is it's own
    entity, ie: "TICPWD" or "TIC password". As far as I've seen,
    message areas and file areas are completely separate from each
    other, and don't use the same passwords.

    Sure, it's technically possible to use different passwords for TIC
    than for binkp, areafix, packets, etc. A straw poll of sysops hasn't shown any of them having a different packet password than the TIC password.

    In my case here, along with every link but one that I connect with, there are no packet passwords whatsoever. My only concern with using the same sbbsecho.cfg option for both, is that if I were to set people up with a file feed, and they specify a password for that, then I would be forced to configure
    a message packet password as well.

    If someone actually has a config like that and can explain why, I'll consider it, but it would need the same wildcard ability as the PKTPWD lines in sbbsecho.cfg. All of these passwords (with the exception of
    the binkp one) basically do the same thing in the same way over the
    same link.

    I see what you're saying. I originally asked from my own perspective. I have over 70 links here, and if I were to start using this I would have to contact each and every one of them that gets a file feed from me, to make sure they now
    have to setup a packet password in order for their future TIC files to work while still receiving message packets.

    If you don't see an issue with something like that, then by all means continue and disregard what I've said.

    If your uplink never asked you for a TIC password, then maybe he
    just made it the same as your packet password.

    I never selected a TICK password because I never wanted the files.
    Only reason I know what my TICK password is is because it's
    transferred in plain text in the TIC file.

    For example, If I was to use all of the husky tools (ie: no
    Synchronet), I would use both HPT (for echomail and netmail) and
    HTICK (for files). There is separate config file options for
    pktpwd and ticpwd, which is why I was confused and asked you about
    it.

    Sure, it's technically possible, but tickit.js is not intended to be a complete TICK solution. I'm not inclined to perpetuate needless complexity, so until there's a problem that needs solving, I'm not
    going to make the script more complex "Just In Case".

    Okay, no worries then. I just gave you a problem that would eventually need solving (or ignoring.. take your pick). You may not see this point of view since you are not a hub/host.. but if it's only meant to be something like Tinytic where it only works for an end point node and not a hub, then nevermind.

    It's possible they're one in the same in some of the older stuff..
    IIRC, Allfix is also separate from anything echomail/netmail
    related, but I never used it so don't know specifics.

    That's the biggest problem I'm seeing with TICK stuff is that the
    majority of it is simply not documented. Some information can be
    gleaned from the various programs that do it, but not enough.

    I see no reason not to require that the packet password and TICK
    password for a link to be the same. If there is a reason, and someone explains it, I'll consider changing that requirement.

    I don't see a reason for them not to be the same either, but in doing so the way you have so far, you're forcing the use of packet passwords (while many choose not to use them at all) if you want to use tickit.js for a file ticker.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Accession@VERT/PHARCYDE to deuce on Tuesday, December 15, 2015 20:58:48
    Hello deuce,

    On 15 Dec 15 15:29, deuce wrote to CVS commit:

    exec tickit.js 1.6 1.7
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv30741

    Modified Files:
    tickit.js
    Log Message:
    Remove the announce message generation. Synchronet has had a new file scan function for a very very long time now, we don't need to
    duplicate this functionality.

    (Unless I misunderstand what the announce message is for?)

    The announce message is basically so that it will either create a text file to be imported into a message base using smbutil, or something that can be imported directly to a message base, announcing any new files received that day.

    There are stat reporting echoes on Fidonet as well as a bunch of othernets specifically for this. And in some cases (ie: Golded+) you can have a personal mail area setup (non-netmail or echomail) where you can import those announcement messages to, in case you didn't have a BBS to list/display and/or newscan files).

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Deuce@VERT/SYNCNIX to Accession on Wednesday, December 16, 2015 03:52:37
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Tue Dec 15 2015 05:25 pm

    In my case here, along with every link but one that I connect with, there are no packet passwords whatsoever. My only concern with using the same sbbsecho.cfg option for both, is that if I were to set people up with a file feed, and they specify a password for that, then I would be forced to configure a message packet password as well.

    I'm not sure what you mean... why would you set them up with a TICK password? If you (as the hub) don't configure a TICK password, there will be no Pw lines in the TIC file. If there's no PKTPWD lines in their sbbsecho.cfg, and you don't include a password in the TIC file, it should Just Work.

    I see what you're saying. I originally asked from my own perspective. I have over 70 links here, and if I were to start using this I would have to contact each and every one of them that gets a file feed from me, to make sure they now
    have to setup a packet password in order for their future TIC files to work while still receiving message packets.

    So if you're the file source, you control if a password is included in the TIC file, not them. It is only in the case where you send them a TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it doesn't really make sense to use one and not the other.

    If you don't see an issue with something like that, then by all means continue and disregard what I've said.

    I'm not discregarding what you're saying. If I were, I would not be replying. Please don't assume that something other than complete agreement with everything you say is disregarding what you say.

    I'm trying to have a discussion here, and you're complaining that I don't listen.

    Okay, no worries then. I just gave you a problem that would eventually need solving (or ignoring.. take your pick). You may not see this point of view since you are not a hub/host.. but if it's only meant to be something like Tinytic where it only works for an end point node and not a hub, then nevermind.

    I do not have a problem. You theorized that a problem might exist and now that I'm talking about how it would happen, you're complaining that I ignore you and can't see your point of view because I'm not a hub/host.


    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Wednesday, December 16, 2015 03:56:55
    Re: Re: exec/tickit.js
    By: Accession to deuce on Tue Dec 15 2015 08:58 pm

    The announce message is basically so that it will either create a text file to be imported into a message base using smbutil, or something that can be imported directly to a message base, announcing any new files received that day.

    Right, and since Tickit.js only supports Synchronet, and Synchronet has new file scan support, this use case doesn't make much sense.

    There are stat reporting echoes on Fidonet as well as a bunch of othernets specifically for this

    The existance of these is what prompted removing the announce message. A Tickit announce ended up in FidoREQ, and I doubt the files are available for FREQ.

    As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.


    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Accession@VERT/PHARCYDE to Deuce on Wednesday, December 16, 2015 14:56:10
    Hello Deuce,

    On 16 Dec 15 03:52, Deuce wrote to Accession:

    In my case here, along with every link but one that I connect with,
    there are no packet passwords whatsoever. My only concern with
    using the same sbbsecho.cfg option for both, is that if I were to
    set people up with a file feed, and they specify a password for
    that, then I would be forced to configure a message packet password
    as well.

    I'm not sure what you mean... why would you set them up with a TICK password? If you (as the hub) don't configure a TICK password, there
    will be no Pw lines in the TIC file. If there's no PKTPWD lines in
    their sbbsecho.cfg, and you don't include a password in the TIC file,
    it should Just Work.

    I set them all up with a TIC password because the option was there and separate
    from sbbsecho's PKTPWD line (using Husky's HTICK with Synchronet). If I were to
    want to move over to utilize something you've made work well with Synchronet, it's going to be a pain in the ass adding everyone's TIC password as a PKTPWD line, and then telling them that their echomail/netmail won't be processed at their system due to me having to add a PKTPWD in replacement of their TIC password.

    I see what you're saying. I originally asked from my own
    perspective. I have over 70 links here, and if I were to start
    using this I would have to contact each and every one of them that
    gets a file feed from me, to make sure they now have to setup a
    packet password in order for their future TIC files to work while
    still receiving message packets.

    So if you're the file source, you control if a password is included in
    the TIC file, not them. It is only in the case where you send them a
    TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it
    doesn't really make sense to use one and not the other.

    What's already done is done. I've been using TIC passwords for years now for *some* inkling of security. I felt that with the use of a CRAM-MD5 encrypted binkp connection, there was no need for packet password.

    If you don't see an issue with something like that, then by all
    means continue and disregard what I've said.

    I'm not discregarding what you're saying. If I were, I would not be replying. Please don't assume that something other than complete
    agreement with everything you say is disregarding what you say.

    ...?

    I never assumed anything. I only said that if you don't see my situation proposed as an issue of any sort, disregard it. Not that you were already disregarding anything.

    I'm trying to have a discussion here, and you're complaining that I
    don't listen.

    So am I, and no I'm not. Maybe you're not comprehending what I'm typing? I never said you don't listen. I basically said that you don't need to listen to me if you don't agree with me that it is an issue intermixing two completely different things (ie: message packets and TICs + files).

    Okay, no worries then. I just gave you a problem that would
    eventually need solving (or ignoring.. take your pick). You may not
    see this point of view since you are not a hub/host.. but if it's
    only meant to be something like Tinytic where it only works for an
    end point node and not a hub, then nevermind.

    I do not have a problem. You theorized that a problem might exist and
    now that I'm talking about how it would happen, you're complaining
    that I ignore you and can't see your point of view because I'm not a hub/host.

    Again, you must not have read what I wrote correctly.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Accession@VERT/PHARCYDE to Deuce on Wednesday, December 16, 2015 15:07:26
    Hello Deuce,

    On 16 Dec 15 03:56, Deuce wrote to Accession:

    The announce message is basically so that it will either create a
    text file to be imported into a message base using smbutil, or
    something that can be imported directly to a message base,
    announcing any new files received that day.

    Right, and since Tickit.js only supports Synchronet, and Synchronet
    has new file scan support, this use case doesn't make much sense.

    It basically lets others know what new files your system received that day, without having to connect to your BBS on a daily basis. All other tickers out there do it, so please don't shoot the messenger.

    There are stat reporting echoes on Fidonet as well as a bunch of
    othernets specifically for this

    The existance of these is what prompted removing the announce message.
    A Tickit announce ended up in FidoREQ, and I doubt the files are
    available for FREQ.

    If the system (like mine, and a bunch of others I know of) manually move files around using scripts, as well as some kind of FREQ handler, then I don't doubt at all that the files are available via FREQ. YMMV.

    As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.

    Reporting ALL files on a daily basis? I don't think that's what the announce message was intended for whatsoever.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Lord Time@VERT/TIME to Deuce on Wednesday, December 16, 2015 12:13:27
    Re: Re: exec/tickit.js
    By: Accession to deuce on Mon Dec 14 2015 06:10 am

    Verify the password in the TIC matches the PKTPWD in sbbsecho.cfg.

    Shouldn't this be a new option field? If you don't have a PKTPWD set for echomail/netmail, you would still have to enable this, therefore enabling message packet passwords, in order to use TICs properly?

    I honestly have no idea. I found zero information about all the different passwords that a FidoNet configuration has and how they interact. All I know is that the TIC files I got from my hub have their Pw set as my PKTPWD. The (brand new -- thanks Michiel van der Vlist) FSP-1039 document does not reccomend accepting files without a password.

    Where does the hub get the password it puts into the TIC files if not from the packet password?

    I have the areafix (messages) be sbbsecho one pw, while allfix dose fdn's and has a differnet pw.

    also I thought to add, a way to post the new files got in some echos (more like a bunch of them)


    ---

    Rob Starr
    Lord Time SysOp of
    Time Warp of the Future BBS
    Telnet://Time.Darktech.Org:24 or
    Telnet://Time.Synchro.Net:24 (qwk or ftn & e-mail)
    ICQ # 11868133 or # 70398519 Jabber : lordtime2000@gmail.com
    Yahoo : lordtime2000 AIM : LordTime20000 MSN : Lord Time
    Astra : lord_time X-Box : Lord Time 2000 oovoo : lordtime2000
    ---
    þ Synchronet þ Time Warp of the Future BBS - Home of League 10 IBBS Games
  • From Deuce@VERT/SYNCNIX to Accession on Thursday, December 17, 2015 10:36:27
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Wed Dec 16 2015 02:56 pm

    So if you're the file source, you control if a password is included in the TIC file, not them. It is only in the case where you send them a TIC file with a password in it that they would need to use a packet password. Since the two passwords provide the same utility, it
    doesn't really make sense to use one and not the other.

    What's already done is done. I've been using TIC passwords for years now for *some* inkling of security. I felt that with the use of a CRAM-MD5 encrypted binkp connection, there was no need for packet password.

    Why do/did you feel that fire transfers need some extra "security", but packets don't?

    Honestly, what I would end up suggesting if all your links are binkp is to simply drop the TICK password just like you did the packet password rather
    than add a packet password. It really doesn't add any extra security at all unless the system is misconfigured.

    Again, you must not have read what I wrote correctly.

    Or it was worded poorly.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Thursday, December 17, 2015 10:49:48
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Wed Dec 16 2015 03:07 pm

    It basically lets others know what new files your system received that day, without having to connect to your BBS on a daily basis. All other tickers out there do it, so please don't shoot the messenger.

    I'm trying to better understand it... so the idea is that you post a message to a networked sub so that your users won't call your BBS or that users will call your BBS, download a file, and disconnect? And this is something Sysops want?

    If the system (like mine, and a bunch of others I know of) manually move files around using scripts, as well as some kind of FREQ handler, then I don't doubt at all that the files are available via FREQ. YMMV.

    I tried a few FREQs... no files have been recieved yet. I didn't try your BBS or others that appeared likely to actually work. Maybe I should try one to make sure a FREQ works at all I suppose.

    As for stat reporting stuff, it makes more sense to report *all* files rather than just ones that came in via an FDS. This would be a very different script... and again, does not belong in ticit.js.

    Reporting ALL files on a daily basis? I don't think that's what the announce message was intended for whatsoever.

    Sorry, I meant all new files... not just ones that came via FDS.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From deuce@VERT to CVS commit on Thursday, December 17, 2015 11:56:03
    exec tickit.js 1.7 1.8
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv8090

    Modified Files:
    tickit.js
    Log Message:
    Explicitly check for empty and undefined passwords and match them to no
    PKTPWD line.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Accession@VERT/PHARCYDE to Deuce on Thursday, December 17, 2015 17:16:40
    Hello Deuce,

    On 17 Dec 15 10:49, Deuce wrote to Accession:

    It basically lets others know what new files your system received
    that day, without having to connect to your BBS on a daily basis.
    All other tickers out there do it, so please don't shoot the
    messenger.

    I'm trying to better understand it... so the idea is that you post a message to a networked sub so that your users won't call your BBS or
    that users will call your BBS, download a file, and disconnect? And
    this is something Sysops want?

    Not so much. More like it let's people that *don't* call your BBS know what files were processed by your TIC processor that day. If one of those files may happen to interest them, maybe they would call for the first time to grab it..?

    I don't know. You can probably look at it a half of a dozen ways.

    If the system (like mine, and a bunch of others I know of) manually
    move files around using scripts, as well as some kind of FREQ
    handler, then I don't doubt at all that the files are available
    via FREQ. YMMV.

    I tried a few FREQs... no files have been recieved yet. I didn't try
    your BBS or others that appeared likely to actually work. Maybe I
    should try one to make sure a FREQ works at all I suppose.

    In order for my FREQ processor to work, the file I receive here must have the .REQ extension. Some people try sending regular netmails or .MSG, and it won't work with that.

    Reporting ALL files on a daily basis? I don't think that's what the
    announce message was intended for whatsoever.

    Sorry, I meant all new files... not just ones that came via FDS.

    That would be fine as well. If there were something to handle that, it may even
    be a better idea. Most of these tic processors are 3rd party utilities, so they
    do their own announcements.

    Since yours is only going to be used with Synchronet, the sky's the limit.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Accession@VERT/PHARCYDE to Deuce on Thursday, December 17, 2015 17:22:50
    Hello Deuce,

    On 17 Dec 15 10:36, Deuce wrote to Accession:

    What's already done is done. I've been using TIC passwords for
    years now for *some* inkling of security. I felt that with the use
    of a CRAM-MD5 encrypted binkp connection, there was no need for
    packet password.

    Why do/did you feel that fire transfers need some extra "security",
    but packets don't?

    Because files can contain executables, which can contain a virus. The worst you
    can do with a message packet is bomb someone with a 512mb sized one, as has happened in the past in Fidonet.

    Before my tic processor runs, I also run a daily updated clamAV on those received files, whereas message bundles don't need that either.

    Honestly, what I would end up suggesting if all your links are binkp
    is to simply drop the TICK password just like you did the packet
    password rather than add a packet password. It really doesn't add any extra security at all unless the system is misconfigured.

    Ok.

    Again, you must not have read what I wrote correctly.

    Or it was worded poorly.

    While my opinion on the matter may be biased, I specifically re-read what I wrote to you, and what you replied with, and you seemed to have conjured up some things I said that I never did. So there's also the possibility that my messages to you were received poorly.

    Mayhaps we should just agree to disagree.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Deuce@VERT/SYNCNIX to Accession on Thursday, December 17, 2015 17:28:08
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Thu Dec 17 2015 05:16 pm

    Sorry, I meant all new files... not just ones that came via FDS.

    That would be fine as well. If there were something to handle that, it may even be a better idea. Most of these tic processors are 3rd party utilities, so they do their own announcements.

    If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Thursday, December 17, 2015 17:39:18
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Thu Dec 17 2015 05:22 pm

    What's already done is done. I've been using TIC passwords for
    years now for *some* inkling of security. I felt that with the use
    of a CRAM-MD5 encrypted binkp connection, there was no need for
    packet password.

    Why do/did you feel that fire transfers need some extra "security",
    but packets don't?

    Because files can contain executables, which can contain a virus. The worst you
    can do with a message packet is bomb someone with a 512mb sized one, as has happened in the past in Fidonet.

    Well, there's also the impersonation angle. Not sure how a TICK password will help protect against a virus... and your system shouldn't be running files it gets.

    But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they are adds nothing except a password in plain text. In the not unusual case where the TICK password and binkp password are the same, this actually lowers security.

    Before my tic processor runs, I also run a daily updated clamAV on those received files, whereas message bundles don't need that either.

    Yeah, this is clearly a good idea.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Ray Quinn@VERT to Deuce on Friday, December 18, 2015 05:17:56
    Hello Deuce!

    17 Dec 15 17:39, you wrote to Accession:


    But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they
    are adds nothing except a password in plain text. In the not unusual
    case where the TICK password and binkp password are the same, this actually lowers security.

    Every network I participate in uses TIC passwords. These are set up as extra "security" between the uplink and the downlink. New passwords are placed in the
    newly generated TIC file for the next downlink(s), and the next, etc. It is similar to a session password with Binkd and even EMSI, etc. I use HTICK and if
    the password in the TIC file doesn't match what I have configured in the HTICK config file, it fails and renames the *.TIC file to *.BAD. I guess that is similar to a packet password...

    Keep up the good work. New "features" are always welcome.


    Ray


    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: Ray's Road Node - Somewhere in California. (1:214/23)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Accession@VERT/PHARCYDE to Deuce on Friday, December 18, 2015 16:28:50
    Hello Deuce,

    On 17 Dec 15 17:28, Deuce wrote to Accession:

    Re: Re: exec/tickit.js
    By: Accession to Deuce on Thu Dec 17 2015 05:16 pm

    Sorry, I meant all new files... not just ones that came via
    FDS.

    That would be fine as well. If there were something to handle that,
    it may even be a better idea. Most of these tic processors are 3rd
    party utilities, so they do their own announcements.

    If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

    I probably would switch over to a new native Synchronet feature it it did all the things my current software does. So I would definitely vote yes on that, as
    well as tickit.js being able to forward to downlinks, which is why I stopped using Tinytic a couple years back.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Accession@VERT/PHARCYDE to Deuce on Friday, December 18, 2015 16:34:20
    Hello Deuce,

    On 17 Dec 15 17:39, Deuce wrote to Accession:

    Because files can contain executables, which can contain a virus.
    The worst you can do with a message packet is bomb someone with a
    512mb sized one, as has happened in the past in Fidonet.

    Well, there's also the impersonation angle. Not sure how a TICK
    password will help protect against a virus... and your system
    shouldn't be running files it gets.

    True, but I tend to worry more about security when a file that could possibly contain an executable is passed on from my system to many others. That's really
    my only reasoning for adding the TIC password as well as running AV on them.

    But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they
    are adds nothing except a password in plain text. In the not unusual
    case where the TICK password and binkp password are the same, this actually lowers security.

    Sure, but isn't that specific TIC password only processed in plain text locally
    with one's tic processor? It's not transmitted over a connection or anything (except inside the file). Or am I understanding that wrong?

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Deuce@VERT/SYNCNIX to Ray Quinn on Friday, December 18, 2015 18:11:58
    Re: exec/tickit.js
    By: Ray Quinn to Deuce on Fri Dec 18 2015 05:17 am

    Every network I participate in uses TIC passwords. These are set up as extra "security" between the uplink and the downlink. New passwords are placed in the
    newly generated TIC file for the next downlink(s), and the next, etc. It is similar to a session password with Binkd and even EMSI, etc. I use HTICK and if
    the password in the TIC file doesn't match what I have configured in the HTICK config file, it fails and renames the *.TIC file to *.BAD. I guess that is similar to a packet password...

    It is the same as a packet password. Do your networks not set a packet password, but do set a TICK password? If so, does anyone know why, or is it just a "we've always done it this way, so this is the way we do it."

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Friday, December 18, 2015 18:17:44
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Fri Dec 18 2015 04:28 pm

    That would be fine as well. If there were something to handle that,
    it may even be a better idea. Most of these tic processors are 3rd
    party utilities, so they do their own announcements.

    If anyone is actually interested in this, let me know. It's a trivial script to write, but I'm not sure anyone wants it.

    I probably would switch over to a new native Synchronet feature it it did all the things my current software does. So I would definitely vote yes on that, as
    well as tickit.js being able to forward to downlinks, which is why I stopped using Tinytic a couple years back.

    So basically a script that will generate a (customizable) list of new files since the last time it ran or the specified period in a configured set of areas?

    As for tickit.js forwarding, I'll take a look at that... it would likely be FLO style only (at least initially) and I'm not sure I've heard a convincing argument to support separate TICK/Packet passwords, so that "feature" would likely not be a priority either.

    Simple FLO forwarding using the existing configs may be easily doable.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Friday, December 18, 2015 18:20:16
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Fri Dec 18 2015 04:34 pm

    But the point is that since there's a binkp authentication, having the TICK processor *also* verify that the other end is who they say they are adds nothing except a password in plain text. In the not unusual case where the TICK password and binkp password are the same, this actually lowers security.

    Sure, but isn't that specific TIC password only processed in plain text locally
    with one's tic processor? It's not transmitted over a connection or anything (except inside the file). Or am I understanding that wrong?

    The password is only in the TIC file from source to destination in plaintext in the transferred file.

    If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over the socket (as part of the file).

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Accession@VERT/PHARCYDE to Deuce on Friday, December 18, 2015 21:58:24
    Hello Deuce,

    On 18 Dec 15 18:17, Deuce wrote to Accession:

    I probably would switch over to a new native Synchronet feature it
    it did all the things my current software does. So I would
    definitely vote yes on that, as well as tickit.js being able to
    forward to downlinks, which is why I stopped using Tinytic a couple
    years back.

    So basically a script that will generate a (customizable) list of new files since the last time it ran or the specified period in a
    configured set of areas?

    Sure, including everything that was TIC'd and uploaded via the BBS, definitely.
    Or an option to either post it directly to a Synchronet message base, or drop the results to a text file to be inserted via smbutil. Either or..

    As for tickit.js forwarding, I'll take a look at that... it would
    likely be FLO style only (at least initially) and I'm not sure I've
    heard a convincing argument to support separate TICK/Packet passwords,
    so that "feature" would likely not be a priority either.

    You may get some flack from the people using the old file attach mailers, but..
    I've known you for awhile, and you've only dealt with binkp for quite some time
    now. In my case, I wouldn't be worried about that.

    Although I do still ask for a separate sbbsecho.cfg option. TICPWD could be separate from PKTPWD only for people that are file security nincompoops. :)

    Simple FLO forwarding using the existing configs may be easily doable.

    Right on!

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Accession@VERT/PHARCYDE to Deuce on Friday, December 18, 2015 22:03:44
    Hello Deuce,

    On 18 Dec 15 18:20, Deuce wrote to Accession:

    Sure, but isn't that specific TIC password only processed in plain
    text locally with one's tic processor? It's not transmitted over a
    connection or anything (except inside the file). Or am I
    understanding that wrong?

    The password is only in the TIC file from source to destination in plaintext in the transferred file.

    If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over
    the socket (as part of the file).

    I request at the VERY LEAST cram-md5 for the binkp connection. I think just about all of my 70+ connections have been able to do that. Ones running older mailers may not have that option, and for those specific to that I've made accomodations.

    With that said, Synchronet is able to handle what you throw at it. So I thank you and Rob for that, of course. And when you come out with a new feature that could potentially be usable to me without having to use 3rd party stuff.. I will nitpick at it until I can actually feel good using it. :D :D :D

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Deuce@VERT/SYNCNIX to Accession on Saturday, December 19, 2015 11:47:05
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Fri Dec 18 2015 09:58 pm

    As for tickit.js forwarding, I'll take a look at that... it would likely be FLO style only (at least initially) and I'm not sure I've heard a convincing argument to support separate TICK/Packet passwords, so that "feature" would likely not be a priority either.

    You may get some flack from the people using the old file attach mailers, but.. I've known you for awhile, and you've only dealt with binkp for quite some time now. In my case, I wouldn't be worried about that.

    The main issue with supporting attach style is that I wouldn't be able to test it... and I know that FidoNuts hate it any time some new software appears on their network doing something they don't expect.

    Although I do still ask for a separate sbbsecho.cfg option. TICPWD could be separate from PKTPWD only for people that are file security nincompoops. :)

    Yeah, until someone gives me a reason that makes sense, this is going to stay a "no". FidoNet has a lot of stupid due to lack of understanding and fear of breaking some TRS-80 mailer. I'll not contribute to that culture.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From Deuce@VERT/SYNCNIX to Accession on Saturday, December 19, 2015 11:48:46
    Re: Re: exec/tickit.js
    By: Accession to Deuce on Fri Dec 18 2015 10:03 pm

    If using a non-encrypted binkp connection (CRAM-MD5 and crypt are different features), the password gets transmitted in plain text over the socket (as part of the file).

    I request at the VERY LEAST cram-md5 for the binkp connection. I think just about all of my 70+ connections have been able to do that. Ones running older mailers may not have that option, and for those specific to that I've made accomodations.

    Do you ensure that the binkp password is different to the TIC password? 'cause if not, the TIC password is a huge security hole. Same with the Areafix password.

    ---
    http://DuckDuckGo.com/ a better search engine that respects your privacy.
    Mro is an idiot. Please ignore him, we keep hoping he'll go away.
    þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
  • From deuce@VERT to CVS commit on Sunday, January 03, 2016 14:56:05
    exec tickit.js 1.8 1.9
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv16266

    Modified Files:
    tickit.js
    Log Message:
    Don't return false if no pktpass line matches the node so that the test
    for empty/undefined can occur.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 07, 2016 18:49:32
    exec tickit.js 1.9 1.10
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv18885

    Modified Files:
    tickit.js
    Log Message:
    Re-organize the INI file laout and prepare to support downlinks.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 07, 2016 19:49:05
    exec tickit.js 1.10 1.11
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv21930

    Modified Files:
    tickit.js
    Log Message:
    If we can't move the file to the final location, fail processing and don't delete the TIC file.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 07, 2016 22:10:17
    exec tickit.js 1.11 1.12
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv26138

    Modified Files:
    tickit.js
    Log Message:
    Add circular path detection and file forwarding.
    This could now be considered "full featured" since there's no more features
    I currently plan on adding.

    Have at 'er!




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Saturday, January 09, 2016 23:28:16
    exec tickit.js 1.13 1.14
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv8621

    Modified Files:
    tickit.js
    Log Message:
    Add a "how to set up" comment at the start... this info will go on the Wiki
    as well.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Sunday, January 10, 2016 21:37:57
    exec tickit.js 1.14 1.15
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv5437

    Modified Files:
    tickit.js
    Log Message:
    Add all our fidonet addresses to the seen by list when forwarding TIC files.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Sunday, January 10, 2016 22:29:28
    exec tickit.js 1.15 1.16
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv7027

    Modified Files:
    tickit.js
    Log Message:
    Bugfix: Put Seenby addresses in Seenby lines, not Path lines (eek!)



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Sunday, January 10, 2016 22:58:32
    exec tickit.js 1.16 1.17
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv8970

    Modified Files:
    tickit.js
    Log Message:
    Fix address parsing and outbound path calculation.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Monday, January 11, 2016 14:18:18
    exec tickit.js 1.17 1.18
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv17880

    Modified Files:
    tickit.js
    Log Message:
    Add support for points, and create the outbound directory (using mkpath()) if it doesn't exist.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 14, 2016 00:28:43
    exec tickit.js 1.19 1.20
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv13859

    Modified Files:
    tickit.js
    Log Message:
    Fix typo in error message.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 14, 2016 01:01:55
    exec tickit.js 1.20 1.21
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv4452

    Modified Files:
    tickit.js
    Log Message:
    Fix bug in forwarding TIC files reported by DeepEND.
    Thanks!



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Friday, January 22, 2016 18:25:46
    exec tickit.js 1.21 1.22
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv27820

    Modified Files:
    tickit.js
    Log Message:
    Bugfix: Description offset comes before the size offset.
    Thanks for the report!




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Sunday, January 24, 2016 12:53:02
    exec tickit.js 1.22 1.23
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv18428

    Modified Files:
    tickit.js
    Log Message:
    Use String.repeat() instead of a fixes string... it looks like there may have been an extra space in there.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 28, 2016 12:55:43
    exec tickit.js 1.23 1.24
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv12880

    Modified Files:
    tickit.js
    Log Message:
    Polyfill the String.prototype.repeat() method.
    Some better polyfill method should be worked out at some point...



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, January 28, 2016 13:02:10
    exec tickit.js 1.24 1.25
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv13191

    Modified Files:
    tickit.js
    Log Message:
    Filenames are 12 characters long, not 11 (the dot is included).




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Joe Delahaye@VERT to deuce on Thursday, January 28, 2016 19:01:39
    Re: exec/tickit.js
    By: deuce to CVS commit on Thu Jan 28 2016 13:02:10

    Modified Files:
    tickit.js
    Log Message:
    Filenames are 12 characters long, not 11 (the dot is included).


    If it is DOS format (8-3) and you include the dot, then it would be 13 I think, Unless I am out in left field someplace, and thinking about something completely different <G>
    --- SBBSecho 2.33-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Deuce@VERT/BBSDEV to Joe Delahaye on Friday, January 29, 2016 02:06:41
    Re: exec/tickit.js
    By: Joe Delahaye to deuce on Thu Jan 28 2016 07:01 pm

    Filenames are 12 characters long, not 11 (the dot is included).


    If it is DOS format (8-3) and you include the dot, then it would be 13 I think, Unless I am out in left field someplace, and thinking about something completely different <G>

    8+3+strlen(".") == 12.

    I think you're thinking about something different. :-)

    ---
    þ Synchronet þ The future of BBSing
  • From Accession@VERT/PHARCYDE to Joe Delahaye on Thursday, January 28, 2016 20:10:48
    Hello Joe,

    On 28 Jan 16 19:01, Joe Delahaye wrote to deuce:

    If it is DOS format (8-3) and you include the dot, then it would be 13
    I think, Unless I am out in left field someplace, and thinking about something completely different <G>

    I demand a recount! :)

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20151129
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
    þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Joe Delahaye@VERT to Deuce on Thursday, January 28, 2016 23:04:46
    Re: exec/tickit.js
    By: Deuce to Joe Delahaye on Fri Jan 29 2016 02:06:41

    If it is DOS format (8-3) and you include the dot, then it would be 13
    I think, Unless I am out in left field someplace, and thinking about
    something completely different <G>

    8+3+strlen(".") == 12.

    I think you're thinking about something different. :-)

    Actually, I'm mis counting :( Shame on me.
    --- SBBSecho 2.33-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From Joe Delahaye@VERT to Accession on Friday, January 29, 2016 09:08:50
    Re: Re: exec/tickit.js
    By: Accession to Joe Delahaye on Thu Jan 28 2016 20:10:48

    If it is DOS format (8-3) and you include the dot, then it would be
    13 I think, Unless I am out in left field someplace, and thinking
    about something completely different <G>

    I demand a recount! :)

    You got it <G>
    --- SBBSecho 2.33-Win32
    * Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Sunday, February 28, 2016 17:06:37
    exec tickit.js 1.25 1.26
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv5783

    Modified Files:
    tickit.js
    Log Message:
    Add correct handling for Replaces line.
    If Replaces is the same as the new filename, replace it. Otherwise, return
    and error and process the next TIC file.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Tuesday, March 01, 2016 17:10:40
    exec tickit.js 1.26 1.27
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv7888

    Modified Files:
    tickit.js
    Log Message:
    Return false when logging an error about a lack of a replaces line.
    Should prevent TIC file from being incorrectly deleted.

    Thanks drakahn99!



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From deuce@VERT to CVS commit on Thursday, May 12, 2016 03:14:09
    exec tickit.js 1.27 1.28
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv12073

    Modified Files:
    tickit.js
    Log Message:
    Re-order load()s



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From rswindell@VERT to CVS commit on Wednesday, October 18, 2017 23:13:45
    exec tickit.js 1.38 1.39
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv13563

    Modified Files:
    tickit.js
    Log Message:
    Nelgin's mod to add separate TIC File password support.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Monday, December 04, 2017 21:46:55
    exec tickit.js 1.39 1.40
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv1233

    Modified Files:
    tickit.js
    Log Message:
    Initialize the tic desc to an empty string since it's later assumed to
    be defined.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Monday, December 04, 2017 21:56:31
    exec tickit.js 1.40 1.41
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv2302

    Modified Files:
    tickit.js
    Log Message:
    Don't strip leading whitespace from "desc" and "ldesc" lines.

    A lot of LDesc stuff has leading whitespace.




    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Monday, April 02, 2018 13:32:13
    exec tickit.js 1.41 1.42
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv28572

    Modified Files:
    tickit.js
    Log Message:
    Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to rswindell on Monday, April 02, 2018 21:38:32
    On 2018 Apr 02 13:32:12, you wrote to CVS commit:

    exec tickit.js 1.41 1.42
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv28572

    Modified Files:
    tickit.js
    Log Message:
    Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.

    might want to call that "-forcereplace" or similar... most other FTN file processors use something like "-replace" to enable replacing IF the TIC has the
    REPLACES verb in it... some sysops do not want the older files replaced automatically so their processor has an option to ignore the REPLACES verb... in some cases, following REPLACES in some areas and ignoring it in others is a good thing so some processors may make this option a per area setting...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... You know. That old guy who carried moderation to excess.
    ---
    * Origin: (1:3634/12.73)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Tuesday, April 03, 2018 18:52:19
    exec tickit.js 1.42 1.43
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv10683

    Modified Files:
    tickit.js
    Log Message:
    Change the -replace option to -force-replace since the old "tick" program
    had a "replace" option that did something differnet (enabled parsing of the REPLACES verb) - don't want to confuse sysops now. :-)



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Tuesday, April 17, 2018 14:45:28
    exec tickit.js 1.43 1.44
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv17047

    Modified Files:
    tickit.js
    Log Message:
    Simplified the rename_or_move() function:
    - Don't use the deprecated 'e' file open mode
    - Use the global file_copy() method rather than roll-your-own



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From echicken@VERT to CVS commit on Tuesday, August 14, 2018 08:24:28
    exec tickit.js 1.45 1.46
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv17812

    Modified Files:
    tickit.js
    Log Message:
    seem like maybe addrs should be a array



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Nelgin@VERT/EOTLBBS to rswindell on Tuesday, August 14, 2018 15:47:31
    rswindell wrote:
    exec tickit.js 1.41 1.42
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv28572

    Modified Files:
    tickit.js
    Log Message:
    Experimental feature for bgdjr: when '-replace' argument is passed on the command-line, treat all .TIC files as they have have a "REPLACES" clause.

    This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so long and not had to put replace lines in them. I can't be the only one. This will certainly help out
    though it'd helf if we could specify which file areas should force replace and which shouldn't.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Al@VERT/TRMB to Nelgin on Tuesday, August 14, 2018 16:13:48
    Re: Re: exec/tickit.js
    By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

    This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so long and not had to put replace lines in them. I can't be the only one. This will certainly help out though it'd helf if we could specify which file areas should force replace and which shouldn't.

    It would certainly be better if those who hatch files would use the replaces line when needed.

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

    Ttyl :-),
    Al


    ... Don't blame me.. I didn't vote Conservative!

    ---
    þ Synchronet þ The Rusty MailBox - Penticton, BC Canada
  • From Digital Man@VERT to Al on Tuesday, August 14, 2018 18:59:35
    Re: Re: exec/tickit.js
    By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

    Someone actually uses the delfiles utility? Good to know. :-)

    digital man

    Synchronet "Real Fact" #94:
    Synchronet v3.15b was released in October of 2011 (5 years after v3.14a). Norco, CA WX: 79.7øF, 50.0% humidity, 10 mph E wind, 0.00 inches rain/24hrs

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Vk3jed@VERT/FREEWAY to Nelgin on Wednesday, August 15, 2018 11:48:00
    On 08-14-18 15:47, Nelgin wrote to rswindell <=-

    This might stop me ripping Gert a new rear end. I'm sure sure how he's managed to get away with creating nodelists for his networks for so
    long and not had to put replace lines in them. I can't be the only one. This will certainly help out though it'd helf if we could specify which file areas should force replace and which shouldn't.

    I use Replaces in my nodelist and infopack distribution. Only issue I'm having is TickIT keeping the old nodelist around, but it is replacing the infopack, which is the same filename each time.


    ... Hard work has a future payoff. Laziness pays off now.
    --- MultiMail/Win v0.51
    þ Synchronet þ Freeway BBS, Bendigo Australia. freeway.apana.org.au
  • From MRO@VERT/BBSESINF to Digital Man on Tuesday, August 14, 2018 21:30:29
    Re: Re: exec/tickit.js
    By: Digital Man to Al on Tue Aug 14 2018 06:59 pm

    Re: Re: exec/tickit.js
    By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

    Someone actually uses the delfiles utility? Good to know. :-)



    yes, if we have files we use delfiles.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Nelgin@VERT/EOTLBBS to Al on Tuesday, August 14, 2018 22:02:37
    Al wrote:
    Re: Re: exec/tickit.js
    By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

    This might stop me ripping Gert a new rear end. I'm sure sure how he's
    managed to get away with creating nodelists for his networks for so long
    and not had to put replace lines in them. I can't be the only one. This
    will certainly help out though it'd helf if we could specify which file
    areas should force replace and which shouldn't.

    It would certainly be better if those who hatch files would use the replaces line when needed.

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in
    those areas anyway.. :)

    I've been following a sort of side conversation on that. Janis has been giving some hints on how to hack files with a Replaces line.

    Personally, from what I am seeing of the new ZC, I don't much care for his attitude.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Al@VERT/TRMB to Vk3jed on Tuesday, August 14, 2018 20:41:15
    Re: Re: exec/tickit.js
    By: Vk3jed to Nelgin on Wed Aug 15 2018 11:48 am

    I use Replaces in my nodelist and infopack distribution. Only issue I'm having is TickIT keeping the old nodelist around, but it is replacing the infopack, which is the same filename each time.

    I read your comment on this a couple weeks ago and I see it here too. When a new nodelist.z07 comes in and replaces nodelist.z00 the nodelist.z00 isn't removed. Tickit might need a tweak.

    Ttyl :-),
    Al


    ... Plagiarism prohibited, derive carefully.

    ---
    þ Synchronet þ The Rusty MailBox - Penticton, BC Canada
  • From Al@VERT/TRMB to Nelgin on Tuesday, August 14, 2018 20:51:16
    Re: Re: exec/tickit.js
    By: Nelgin to Al on Tue Aug 14 2018 10:02 pm

    I've been following a sort of side conversation on that. Janis has been giving some hints on how to hack files with a Replaces line.

    That's not good. We have to be able to trust that the tics we receive are what the hatching node created, especially when those tics are going to replace files. They should have path and seen bys added but otherwise not modified.

    Personally, from what I am seeing of the new ZC, I don't much care for his attitude.

    The important thing is what he does as ZC. His main duty is to create and distribute the nodelist (along with his other zone partners). As far as I have seen he does a good job of that although I think his tics could use a replaces line.

    I always thought those tics had a replaces line but I could be mistaken.. ;)

    I hope that whatever he does as ZC will build up fidonet and not tear it down.

    Ttyl :-),
    Al


    ... My spelling? Oh, it's just line noise.

    ---
    þ Synchronet þ The Rusty MailBox - Penticton, BC Canada
  • From Nelgin@VERT/EOTLBBS to Al on Wednesday, August 15, 2018 00:31:29
    Al wrote:

    I always thought those tics had a replaces line but I could be mistaken.. ;)

    As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

    Follow the conversation on FN_SYSOP I think it is.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Nelgin@VERT/EOTLBBS to Nelgin on Wednesday, August 15, 2018 00:33:47
    Nelgin wrote:
    Al wrote:

    I always thought those tics had a replaces line but I could be mistaken.. ;)

    As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

    Follow the conversation on FN_SYSOP I think it is.

    Correction Z1C echo group.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Al@VERT/TRMB to Nelgin on Wednesday, August 15, 2018 01:25:51
    Re: Re: exec/tickit.js
    By: Nelgin to Al on Wed Aug 15 2018 12:31 am

    As Janis wrote, "does anyone in Zone 1 or 2 know how to create a tic with Replaces other than me?" lol. Or something like that.

    Follow the conversation on FN_SYSOP I think it is.

    I haven't seen it but I usually "T" my way through there. I'll have a look.

    Ttyl :-),
    Al


    ... All wiyht. Rho sritched mg kegtops awound?

    ---
    þ Synchronet þ The Rusty MailBox - Penticton, BC Canada
  • From Vk3jed@VERT/FREEWAY to Al on Wednesday, August 15, 2018 19:36:00
    On 08-14-18 20:41, Al wrote to Vk3jed <=-

    I read your comment on this a couple weeks ago and I see it here too.
    When a new nodelist.z07 comes in and replaces nodelist.z00 the nodelist.z00 isn't removed. Tickit might need a tweak.

    Yes, that's what I'm seeing here. :) It's not my TIC files, because Mystic removes the old nodelist when it does its import.


    ... Bad Restaurant: Hospital map on the back of the menu.
    --- MultiMail/Win v0.51
    þ Synchronet þ Freeway BBS, Bendigo Australia. freeway.apana.org.au
  • From Bill McGarrity@VERT/TEQUILAM to Digital Man on Wednesday, August 15, 2018 09:14:00
    Digital Man wrote to Al on 08-14-18 18:59 <=-

    Re: Re: exec/tickit.js
    By: Al to Nelgin on Tue Aug 14 2018 04:13 pm

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in those areas anyway.. :)

    Someone actually uses the delfiles utility? Good to know. :-)

    lol... I just used it this morning... :)


    --

    Bill

    Telnet: tequilamockingbirdonline.net
    Web: bbs.tequilamockingbirdonline.net
    FTP: ftp.tequilamockingbirdonline.net:2121
    IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
    Radio: radio.tequilamockingbirdonline.net:8010/live


    ... Look Twice... Save a Life!!! Motorcycles are Everywhere!!!
    --- MultiMail/Win32 v0.50
    þ Synchronet þ TequilaMockingbird Online - Toms River, NJ
  • From Nelgin@VERT/EOTLBBS to Al on Wednesday, August 15, 2018 12:00:00
    Al wrote:
    Re: Re: exec/tickit.js
    By: Nelgin to rswindell on Tue Aug 14 2018 03:47 pm

    This might stop me ripping Gert a new rear end. I'm sure sure how he's
    managed to get away with creating nodelists for his networks for so long
    and not had to put replace lines in them. I can't be the only one. This
    will certainly help out though it'd helf if we could specify which file
    areas should force replace and which shouldn't.

    It would certainly be better if those who hatch files would use the replaces line when needed.

    I noticed in Z1 the nodelist and friends tics don't have a replaces line now either. I set my nodelist and nodediff areas to 90 days and use delfiles to remove old files from those areas now. I suppose there were too many files in
    those areas anyway.. :)

    What options are you using for delfiles? I'd hate to get it wrong!

    I assume you're calling it once per day from the timed events menu option?

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From Al@VERT/TRMB to Nelgin on Wednesday, August 15, 2018 14:18:30
    Re: Re: exec/tickit.js
    By: Nelgin to Al on Wed Aug 15 2018 12:00 pm

    What options are you using for delfiles? I'd hate to get it wrong!

    Yes, we don't want any errors there.. :)

    I only used the -LIB option to point to the fido area. I only have a few areas set to delete old files so it will only do anything there.

    I assume you're calling it once per day from the timed events menu option?

    I am planning on adding it as a weekly event but I just did it once from the command line.

    But wait a minute! A few have asked Z1C to use the replaces verb in tic files. If he does then there is no need to do that. There is probably no need to keep so many old nodelists but I like to keep them around just in case I need to look something up in an old list.

    Ttyl :-),
    Al


    ... "All these doughnuts and not a cop in sight" -- Plucky Duck

    ---
    þ Synchronet þ The Rusty MailBox - Penticton, BC Canada
  • From Nelgin@VERT/EOTLBBS to Al on Wednesday, August 15, 2018 20:46:25
    Al wrote:

    But wait a minute! A few have asked Z1C to use the replaces verb in tic files.
    If he does then there is no need to do that. There is probably no need to keep
    so many old nodelists but I like to keep them around just in case I need to look something up in an old list.

    And he said that it has been done so we'll find out tomorrow.

    ---
    þ Synchronet þ End Of The Line BBS - endofthelinebbs.com
  • From rswindell@VERT to CVS commit on Monday, August 20, 2018 22:15:44
    exec tickit.js 1.46 1.47
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv21424

    Modified Files:
    tickit.js
    Log Message:
    Nelgin's mod (cleaned-up):
    If a tickit.ini area section has "ForceReplace=true", then it'll treat
    all the incoming .tic files for that area as though they have a "Replaces" keyword.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Sunday, September 30, 2018 12:04:47
    exec tickit.js 1.47 1.48
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv17769

    Modified Files:
    tickit.js
    Log Message:
    Added support for an 'uploader' TickIt global option. If specified, this
    value will be passed as the '-x' parameter (uploader) value to addfiles
    when adding files to filebases.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From echicken@VERT to CVS commit on Monday, December 10, 2018 13:34:59
    exec tickit.js 1.48 1.49
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv32518

    Modified Files:
    tickit.js
    Log Message:
    Make the 'no matching replaces line' error more descriptive.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From echicken@VERT to CVS commit on Monday, December 10, 2018 13:38:32
    exec tickit.js 1.49 1.50
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv32717

    Modified Files:
    tickit.js
    Log Message:
    Don't assume the link's gender. This may be a sausagefest but we can
    always pretend otherwise.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From echicken@VERT to CVS commit on Monday, December 17, 2018 07:32:01
    exec tickit.js 1.50 1.51
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv2674

    Modified Files:
    tickit.js
    Log Message:
    Different log messages for absent vs. mismatched Replaces line.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From echicken@VERT to CVS commit on Friday, December 21, 2018 07:08:24
    exec tickit.js 1.51 1.52
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv2898

    Modified Files:
    tickit.js
    Log Message:
    Unmisplace misplaced quotation mark in addfiles command line for uploader's name.
    Spotted and fixed by Mark Lewis.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Thursday, January 17, 2019 09:57:07
    exec tickit.js 1.53 1.54
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv18484

    Modified Files:
    tickit.js
    Log Message:
    add lost code to write existing Path lines to the TIC file - wkitty42



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Monday, April 27, 2020 18:17:00
    exec tickit.js 1.54 1.55
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv363

    Modified Files:
    tickit.js
    Log Message:
    Handle case mismatches with filenames.
    I actually made this change back in January, but I don't remember why/who-for.


    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Saturday, May 16, 2020 13:11:37
    exec tickit.js 1.55 1.56
    Update of /cvsroot/sbbs/exec
    In directory cvs:/tmp/cvs-serv24565

    Modified Files:
    tickit.js
    Log Message:
    For Ragnarok, use the linked-node's crash/hold/normal/direct status configuration when determining the created/appended FLO filename extension.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Tuesday, April 06, 2021 00:41:18
    https://gitlab.synchro.net/main/sbbs/-/commit/25a1b75dfed6766656d89e90
    Modified Files:
    exec/tickit.js
    Log Message:
    Use -debug command-line option if you want the <area> using ... address log

    For Nelgin, to reduce log spam.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sunday, May 09, 2021 23:47:48
    https://gitlab.synchro.net/main/sbbs/-/commit/e0d937bbd5b7843d18b3eda6
    Modified Files:
    exec/tickit.js
    Log Message:
    Don't allow duplicate extended and normal descriptions

    If the extended description and the normal (short) description are the same, delete the extended (long) description.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net