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)

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)

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)

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)

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)

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)

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)

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)

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)

close https://gitlab.synchro.net/main/sbbs/-/issues/260
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)