home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   MAKENL_NG      MakeNL Next Generation.      1,725 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 572 of 1,725   
   mark lewis to Marc Lewis   
   follow-up on: NCs who've updated to Make   
   22 Jan 13 14:16:11   
   
    MarcL> Important to note here - it's NOT the file date that MakeNL is    
    MarcL> looking at, it's the julian extension which it apparently    
    MarcL> calculates on the fly based on the system date/time as to which    
    MarcL> extensions are acceptable.   
      
    ml> ahh! that makes a difference, then... my configs do not use julian   
    ml> dated extensions... i know about them and could use them but for   
    ml> security reasons, do not... this also prevents the creation of   
    ml> netseg diffs but that's never been a problem...   
      
    MarcL> The julian date extension is the default for ALL diffs and lists.    
      
   right... i thought i had noted that i use full filenames, including   
   extensions, and that's why i apparently haven't seen this in my testing...   
      
    MarcL> It, I don't think, would not show up anywhere in your normal    
    MarcL> config file - it's how the segments are normally transmitted    
    MarcL> after whichever program has produced them. E.g., Net9000.018 or   
    MarcL> Net9000.242.  It's the intended distribution date; that's what   
    MarcL> MakeNL is looking at in the Master directory and calculating the   
    MarcL> file's relative age from that extension.   
      
   unless you use a specific extension (that your upstream *C knows about and   
   configures for)... of course, that also means that historic files are not   
   available as each new rendition of the specific filename would have to   
   overwrite previous the one when it is hatched out to others in the region or   
   net if one does that for those in their coverage area...   
      
   i had thought that it was looking at the file's date(s) instead of the   
   extension... i can see where the extension in the julian day serialized   
   methodology is ok but we also know that there can be problems... but the same   
   is true with looking at the dates, as well...   
      
   i can also understand the software automatically saving the last one, two or   
   three submittal files as noted in the history file and documentation but i   
   have to wonder if something like that is better left up to the operator to   
   do... back in the day, there weren't as many tools available as there are   
   today but then again, having the software manage it is also easier and puts   
   the onus on the coder(s) to get it right ;)   
      
   )\/(ark   
      
   ---    
    * Origin:  (1:3634/12.42)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca