1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • Can there be any fault-tolerance built into tickit.js?

    From Craig Hendricks@1:103/705 to GitLab issue in main/sbbs on Fri May 7 08:54:21 2021
    open https://gitlab.synchro.net/main/sbbs/-/issues/260

    https://gitlab.synchro.net/main/sbbs/-/blob/master/exec/tickit.js#L640I regularly receive nodelist TICs containing incorrect size values from a hub. The hub seems to be unable to fix the TIC's size values when informed about it.When there's a length mismatch while processing a TIC file, it causes the entire operation for that file to fail, leaving the TIC and the received file unprocessed in /fido/inbound. Does it necessarily have to fail, or could there be some fault-tolerance built in? Something that still logs a warning, but allows the TIC operation to proceed.Something like:``` if (tic.size !== undefined && f.length !== parseInt(tic.size, 10)) { log(LOG_WARNING, "File '"+f.name+"' length mismatch. File is "+f.length+", expected "+tic.size+"."); log(LOG_WARNING, "We'll just use "+f.length+"; since the TIC just has it WRONG..."); tic.size=f.length; //return false; }```Or is it "bad form" in the FTN world to accept a file that doesn't match what the TIC says?
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Fri May 7 09:20:56 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1964

    Personally, as a sysop, I wouldn't accept a tic/file with mismatched sized. There could be many reasons for it, including the file may have been tampered with. If this something that's hatched on the hub or passing through? It sounds like they really need to fix their problem or you need to find a different hub. The only time I would accept a file that would otherwise be rejected would be when there's no "Replaces" line.This is just my option, of course.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Craig Hendricks@1:103/705 to GitLab note in main/sbbs on Fri May 7 10:04:06 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1965

    If this something that's hatched on the hub or passing through? It sounds like they really need to fix their problem or you need to find a different hub.Hatched on the hub. I 100% agree the problem _should_ be fixed on the sending side.However, I'm the only person who's squawked about it so far, and other sysops of non-Sync boards claim they're processing fine for them, so I don't have high hopes that it will be resolved. The response so far is something akin to "that's how allfix is doing it." I imagine those other sysops' systems just have higher tolerance for such issues, so I thought I'd raise the idea here.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri May 7 11:14:51 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1966

    Does the problem file/tic also have a CRC specified? If the length is different, I would also expect a CRC mismatch.It's certainly possible to ignore length mismatches (as shown with your patch) - just got make it opt-in (default to check/refuse files with length mismatches).
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Craig Hendricks@1:103/705 to GitLab note in main/sbbs on Fri May 7 11:36:39 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1967

    Does the problem file/tic also have a CRC specified? If the length is different, I would also expect a CRC mismatch.I did not see a CRC mismatch error reported. I'll capture and check the next problem TIC I receive to confirm whether a CRC is in it.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From waldo kitty@1:103/705 to GitLab note in main/sbbs on Fri May 7 12:17:39 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1968

    yeah, you won't see CRC matched if the file size fails... things are checked in order and if failed, processing is aborted right there... no need to continue with further processing... i think the file size is checked first... i might be willing to bet that there will be a CRC error with your patch in place...if the file size is larger than the TIC says it is, it sounds like the hatching system or another system in the path from the hatcher to your system is adding something to the file... this could be a file_id.diz or even one of those similar info files... the problem is that that should be added to the archive first before the tic is created with the size and CRC values...
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Craig Hendricks@1:103/705 to GitLab note in main/sbbs on Fri May 7 13:26:23 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1969

    i might be willing to bet that there will be a CRC error with your patch in place...It actually succeeded with the patch in place.> this could be a file_id.diz or even one of those similar info files... the problem is that that should be added to the archive first before the tic is created with the size and CRC values...That's exactly what the problem is (removing the file_id.diz file drops the file down to what is specified in the TIC), and I even pointed that out. Hatcher claims to have no control over the order in which the events occur.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From waldo kitty@1:103/705 to GitLab note in main/sbbs on Fri May 7 14:50:36 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1970

    they're full of it, then ;)i'm glad you found a solution...
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Craig Hendricks@1:103/705 to GitLab note in main/sbbs on Fri May 14 07:43:42 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/260#note_1996

    So the hub ended up fixing the issue on their end, so I no longer need my modded tickit.js to process the incoming files. Since I no longer need this modification (for this or any other hub), and I agree with @nelgin about the possible implications of accepting files that don't align with the specs listed in the TIC, I'll close this.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Craig Hendricks@1:103/705 to GitLab issue in main/sbbs on Fri May 14 07:43:42 2021
    close https://gitlab.synchro.net/main/sbbs/-/issues/260
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)