Message Area
Casually read the BBS message area using an easy to use interface. Messages are categorized exactly like they are on the BBS. You may post new messages or reply to existing messages! You are not logged in. Login here for full access privileges. |
Previous Message | Next Message | Back to IFDC FileGate Project(sm) Intern... <-- <--- | Return to Home Page |
|
||||||
From | To | Subject | Date/Time | |||
Janis Kracht | All | Hatching... |
June 10, 2016 6:25 PM * |
|||
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) |
||||||
|
Previous Message | Next Message | Back to IFDC FileGate Project(sm) Intern... <-- <--- | Return to Home Page |
Execution Time: 0.0922 seconds If you experience any problems with this website or need help, contact the webmaster. VADV-PHP Copyright © 2002-2024 Steve Winn, Aspect Technologies. All Rights Reserved. Virtual Advanced Copyright © 1995-1997 Roland De Graaf. |