| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Hatching... |
Hi Folks, This is important. I was pretty sure most everyone realized this, but I guess not. I just want to remind everyone that there is no "open hatching" on the filegate. That means ONLY coordinators of specific FDNs are authorized to release files into the stream... If you are not a File Distribution Coordinator listed with an FDN in Filegate.zxx, you should only pass files received from your uplink to your DOWNLINKS. You should never use the hatch command to distribute some cool file you think the world needs. Send it one of the appropriate coordinators listed in filegate.zxx. Or, if you find a cool file you'd like released, check the FDN list in filegate.zxx to see if that FDN has a "To HeadQuarters" area. You ARE allowed to hatch that new file TO THE COORDINATOR only in that area.. He can test it, fix a long filename problem, and get it out to the rest of Fidonet. I have my system set up to protect against just anyone of my downlinks hatching, however given the way BBBS lets sysops areafix to add file areas, the specific flag to disallow hatching is not added to the node's entry for the area requested automatically ( we want it to be "receive only"). I have to manually add that flag (such as >1:282/xxx) which allows that node to receive files, but does not allow that node to send out files into the stream from here. The way bbbs leaves newly areafixed file areas is to allow hatching and receiving instead, for example, 1:282/xxx. So I have to manually change that nodes' permissions if a new area is requested, etc., from 1:282/xxx to >1:282/xxx. Open Hatching (anyone in fidonet hatching files into the stream) is too impractical, no one takes responsibility for cleaning up mistakes made when a sysop hatches a "mistake" because the sysop hasn't agreed to do it, like the FDN Coordinators have. It can also create dupe file releases and busy up our distribution and unwarranted dupe releases can tie up our mailers unnecessarily... Who need 5 versions of the latest door file, or utility coming from multiple systems multiple times? We had an instance yesterday that I missed because I'm still fighting this sinus infection that knocked me out. It's getting better but it's not gone yet. The point is I missed this happening yesterday until Bob Seaborn contacted me. (Thank you Bob :) The file sent out was : not an 8X3 filename *We cannot release long filenames because many systems cannot deal with them). *I received a number of complaints from sysops who could not process the file. I'll be contacting that sysop shortly. In the meantime, I just wanted to remind everyone that this was not done intentionally by one of the FileGate Coordinators and at for that area the permissions are fixed. When I'm finished with all these meds I'm currently on, I'll go over all the other file areas in my tick config to make sure this does not happen again. Thanks to all for understanding. Take care, Janis --- BBBS/Li6 v4.10 Dada-2* Origin: Prism bbs (1:261/38) SEEN-BY: 14/5 18/200 19/33 34/999 90/1 116/18 120/331 123/500 128/187 140/1 SEEN-BY: 218/700 222/2 230/150 240/1120 249/303 250/1 261/38 100 266/404 SEEN-BY: 267/155 280/1027 282/1056 292/907 908 320/119 219 340/400 393/68 70 SEEN-BY: 633/267 280 640/384 712/620 848 770/1 801/161 189 @PATH: 261/38 712/848 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.