tp@mccall.com (Terry Poot) (05/24/91)
Sorry about the last one, this patch produces RFC822 compatible dates as
best I can tell, and hopefully this will statisfy C news.
In case you don't know by now, a recent change to C news causes it to
discard all postings and followups from dxrn or mxrn if they are built
with GENERATE_EXTRA_FIELDS defined. The format of the Date: header is not
acceptable to the recent version of C news. This probably mostly affects
those ysing dxrn or mxrn to connect to an ANU News nntp server, as it
requires the message to contain Date: headers, whereas most unix based
nntp servers do not.
If you run dxrn or mxrn with GENERATE_EXTRA_FILEDS defined, I strongly
suggest you apply this pastch, as your articles are not being propagated
to the whole net, and will be dropped by even more sites as more of them
upgrade theif version of C news.
Please do not assume that you are unaffected if nobody has told you there
is a problem. The messages printed by C news when it encounters one of
these messages does not give enough information for the C news
administrator to contact you about the problem without doing a fair bit of
work to locate the offending article. Also, there is a great deal of
"somebody else probably told him by now" going on. C news does not attempt
to contact the offending site, but simply prints a message in a log file
and discards the article (meaning, of course, that many sites never receive
it at all, and thus can not warn you about it).
This patch is for dxrn/mxrn version 6.14-4, and assumes that you have
applied the "ANU-NEWS" patch included with that version, and which is
needed to get the correct time in the first place, and has nothing
particularly to do with ANU News. Rick will be including it as a standard
part of the code in the future. That patch must be applied if your gmtime()
returns NULL, as it does with VAX C, and you define GENERATE_EXTRA_FIELDS.
You will also need to define TIMEZONE_ENV in config.h to be the name of
an environment variable (logical name or DCL symbol) that will contain a
valid timezone. As given, it sets it up properly for sites using DECUS
uucp.
If you have applied that patch (which applies correctly with an offset
(I think it was 38 lines) on 6.14-4), then apply this one to get the
Date: header formatted to C news' liking. If you have some other version
of dxrn/mxrn, and you build it with GENERATE_EXTRA_FIELDS defined, I'd
suggest you look at the patch and make similar changes. It shouldn't be
hard.
BTW, it has been suggested to me in email that it would be easier to fix
C news. The authors and proponents of C news don't consider this a problem,
they did it on purpose, and as far as I can tell, most of them really don't
care, since their articles aren't being dropped. The bottom line is that
they refuse to do anything about this, and since many sites run C news,
the only practical option is to conform to their software. I would like to
thank Kenneth Herron and Mark Davies specifically for calling this problem
to my attention (the only 2 that did, world wide, so like I said, don't
assume you don't have a problem just because nobody has told you you do).
I'll be submitting this patch to the vmsnet.sources moderator for posting
so that it will get into the archives and be available to anyone who might
later retrieve dxrn from those archives. I'll also send them to Rick Murphy
(the author) so that he can distribute them to any other places dxrn might
be made available, and include them in future releases. If you know someone
running dxrn that might not read any of these newsgroups, please forward
this to them. In fact, if you know someone not running C news, you might
let him know about the problem with it, so that he can try to find out if
his articles are being discarded. I highly doubt that dxrn/mxrn is the
only software generating things C news doesn't like.
*** compose.c_orig
--- compose.c
**************
*** 2407,2413
return(genid);
}
! #endif
void
followup()
--- 2407,2416 -----
return(genid);
}
! /*
! * generate a valid RFC822 date-time
! */
! static char gendate[40];
static char *gen_date()
{
**************
*** 2409,2414
}
#endif
void
followup()
{
--- 2412,2438 -----
*/
static char gendate[40];
+ static char *gen_date()
+ {
+ time_t clockTime;
+ char *atime, *tz;
+ struct tm *cur_time;
+
+ (void) time(&clockTime);
+ cur_time = gmtime(&clockTime);
+ if(cur_time){
+ atime = asctime(cur_time);
+ tz = "GMT";
+ } else {
+ atime = asctime(localtime(&clockTime));
+ tz = getenv(TIMEZONE_ENV);
+ }
+ sprintf(gendate, "%3s, %2s %3s %2s %8s %s", atime, atime+8, atime+22,
+ atime+11, tz);
+ return(gendate);
+ }
+ #endif
+
void
followup()
{
**************
*** 2418,2429
char *signature, *ptr;
int OldPostingMode = PostingMode;
- #ifdef GENERATE_EXTRA_FIELDS
- time_t clockTime;
- char timeString[40];
- struct tm *cur_time;
- #endif
-
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
return;
--- 2442,2447 -----
char *signature, *ptr;
int OldPostingMode = PostingMode;
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
return;
**************
*** 2469,2490
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) time(&clockTime);
! cur_time = gmtime(&clockTime);
! if(cur_time){
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " GMT");
! } else {
! cur_time = localtime(&clockTime);
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " ");
! (void) strcat(timeString, getenv(TIMEZONE_ENV));
! }
! (void) sprintf(buffer, "Date: %s\n", timeString);
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
--- 2487,2493 -----
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) sprintf(buffer, "Date: %s\n", gen_date());
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
**************
*** 2542,2553
char *signature;
int OldPostingMode = PostingMode;
- #ifdef GENERATE_EXTRA_FIELDS
- time_t clockTime;
- char *ptr, timeString[40];
- struct tm *cur_time;
- #endif
-
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
return;
--- 2545,2550 -----
char *signature;
int OldPostingMode = PostingMode;
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
return;
**************
*** 2589,2610
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) time(&clockTime);
! cur_time = gmtime(&clockTime);
! if(cur_time){
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " GMT");
! } else {
! cur_time = localtime(&clockTime);
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " ");
! (void) strcat(timeString, getenv(TIMEZONE_ENV));
! }
! (void) sprintf(buffer, "Date: %s\n", timeString);
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
--- 2586,2592 -----
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) sprintf(buffer, "Date: %s\n", gen_date());
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
**************
*** 2657,2667
art_num current = newsgroup->current;
char buffer[10000];
char *bufptr;
- #ifdef GENERATE_EXTRA_FIELDS
- time_t clockTime;
- char *ptr, timeString[40];
- struct tm *cur_time;
- #endif
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
--- 2639,2644 -----
art_num current = newsgroup->current;
char buffer[10000];
char *bufptr;
if (ComposeActive) {
mesgPane(XRN_SERIOUS, "Only one composition pane at a time");
**************
*** 2722,2743
(void) strcat(TempString, buffer);
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) time(&clockTime);
! cur_time = gmtime(&clockTime);
! if(cur_time){
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " GMT");
! } else {
! cur_time = localtime(&clockTime);
! (void) strcpy(timeString, asctime(cur_time));
! ptr = index(timeString, '\n');
! *ptr = '\0';
! (void) strcat(timeString, " ");
! (void) strcat(timeString, getenv(TIMEZONE_ENV));
! }
! (void) sprintf(buffer, "Date: %s\n", timeString);
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
--- 2699,2705 -----
(void) strcat(TempString, buffer);
#ifdef GENERATE_EXTRA_FIELDS
/* stuff to generate Message-ID and Date... */
! (void) sprintf(buffer, "Date: %s\n", gen_date());
(void) strcat(TempString, buffer);
(void) sprintf(buffer, "Message-ID: %s\n", gen_id());
(void) strcat(TempString, buffer);
--
Terry Poot <tp@mccall.com> The McCall Pattern Company
(uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road
(800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USAstealth@engin.umich.edu (Mike Pelletier) (05/29/91)
In article <1991May24.082757@mccall.com> tp@mccall.com (Terry Poot) writes: >Sorry about the last one, this patch produces RFC822 compatible dates as >best I can tell, and hopefully this will statisfy C news. > [...] > >BTW, it has been suggested to me in email that it would be easier to fix >C news. Do you care to write software that will shuffle through all the possible permutations of Date: lines and fix them up to something that might not even be correct? Why not just fix the source of the problem, which is your soft- ware that is generating non-compliant Date: header lines. > The authors and proponents of C news don't consider this a problem, >they did it on purpose, and as far as I can tell, most of them really don't >care, since their articles aren't being dropped. The bottom line is that >they refuse to do anything about this, and since many sites run C news, >the only practical option is to conform to their software. I would like to Get it straight -- you're not conforming to their software, you're conforming to internationally recognized standards for Date: line format. Your software was bad all along, and C-news has finally started enforcing the standard. That's all there is to it. -- Mike Pelletier | "Wind & waves are breakdowns in the commitment of The University of Michigan | getting from here to there, but they are the con- College of Engineering | ditions for sailing. Not something to eliminate, Student/Systems Admin | but something to dance with."
sloane@kuhub.cc.ukans.edu (05/30/91)
In article <1991May30.182405.16917@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: > I believe that the intention to be strict was announced about 3 months > before the changes were released. Not in any place that someone not running B or C news would be likely to see it. Announcing a change of this magnitude should have at least gone to all of the news.software.* groups and news.admin. As far as I can tell, it was only announced in news.software.b, not a group that is likely to be read by someone not runnng B or C news. -- USmail: Bob Sloane, University of Kansas Computer Center, Lawrence, KS, 66045 E-mail: sloane@kuhub.cc.ukans.edu, sloane@ukanvax.bitnet, AT&T: (913)864-0444
tp@mccall.com (05/31/91)
>In article <1991May24.082757@mccall.com>, tp@mccall.com (Terry Poot) writes: >> Sorry about the last one, this patch produces RFC822 compatible dates as >> best I can tell, and hopefully this will statisfy C news. *Sigh*. I'm sorry, but I did it again. I just haven't had the time to put into this to be careful about it. Anyway, my fix does work, but the patch I posted was the version before the correct version. It won't work at all. (Obviously, not too many people have applied the patch yet, because the person that called my attention to it eyeballed it, and doesn't run dxrn/mxrn himself.) Anyway, here is a very short patch to fix dxrn/mxrn once and for all. Apply this one AFTER my previous patch. I'm not going to post the whole big mess to 4 newsgroups again. The first patch is useless without this one, apply both in sequence to get a working version of dxrn/mxrn that will interoperate with C news. *** LSRC:[DXRN]COMPOSE.C;4 --- compose.c ************** *** 2427,2434 atime = asctime(localtime(&clockTime)); tz = getenv(TIMEZONE_ENV); } ! sprintf(gendate, "%3s, %2s %3s %2s %8s %s", atime, atime+8, atime+22, ! atime+11, tz); return(gendate); } #endif --- 2427,2434 ----- atime = asctime(localtime(&clockTime)); tz = getenv(TIMEZONE_ENV); } ! sprintf(gendate, "%.3s, %.2s %.3s %.2s %.8s %s", atime, atime+8, atime+4, ! atime+22, atime+11, tz); return(gendate); } #endif -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
tp@mccall.com (05/31/91)
In article <SC5+73G@engin.umich.edu>, stealth@engin.umich.edu (Mike Pelletier) writes: > In article <1991May24.082757@mccall.com> tp@mccall.com (Terry Poot) writes: >>Sorry about the last one, this patch produces RFC822 compatible dates as >>best I can tell, and hopefully this will statisfy C news. >> > [...] >> >>BTW, it has been suggested to me in email that it would be easier to fix >>C news. > > Do you care to write software that will shuffle through all the possible > permutations of Date: lines and fix them up to something that might not even > be correct? Why not just fix the source of the problem, which is your soft- > ware that is generating non-compliant Date: header lines. The routine you describe existed in the previous version of C news. It read the Date: lines produced by dxrn just fine. BTW, dxrn isn't my software, I'm just a user. And I don't want it to fix all permutations of Date: line and turn them into something possibly incorrect, but the de facto standard for Date: lines on usenet has been (for at least the 6 years I've been on net) the set of dates that B news will accept, until now, when the C news community has taken it upon themselves to switch form the de facto standard to the de jure standard with no warning to the rest of the world. >> The authors and proponents of C news don't consider this a problem, >>they did it on purpose, and as far as I can tell, most of them really don't >>care, since their articles aren't being dropped. The bottom line is that >>they refuse to do anything about this, and since many sites run C news, >>the only practical option is to conform to their software. I would like to > > Get it straight -- you're not conforming to their software, you're conforming > to internationally recognized standards for Date: line format. Your software > was bad all along, and C-news has finally started enforcing the standard. Get it straight, dxrn conforms to the internationally recognized standard, but not to the internationally published standard. Cnews switched standards. Therefore, I'm changing dxrn to conform to C news. B news likes the old version just fine. I don't have a problem with switching to the official standard, but it would've been nice to find out about it other than by having my news articles dropped on the floor. Like maybe, before the change was made, so I (or the author) could've fixed dxrn in advance. (I don't buy the idea that nobody would have fixed the software if advance warning were given, I know I would have fixed dxrn even if the author didn't.) You haven't been paying attention to this debate, have you? Nothing I've said here is new. Nice to see you've got the official party line memorized though. Was that in the intro to the patch or something? > That's all there is to it. Yep, pretty typical of the C news community. You don't give a damn what problems you cause others, as long as your software works. Must be another part of the official party line. Could someone send me a copy? It would save you all repeating it over and over. I especially like the way you get from accepting B news formats to accepting random bizarre junk and having to repair it, and since this is impossible, you can't accept the B news formats anymore, even though it wasn't so tough in the previous release. This reasoning has to be published somewhere, I can't imagine so many people inventing it independently. It'd sure be gratifying for someone to admit that this changeover was badly handled. At least then we'd have some indication that a little more effort will be put forth next time to avoid such a mess. (I'm sure there will be a next time, since it is C news' mission to save the world from non-conformant software.) -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
rickert@mp.cs.niu.edu (Neil Rickert) (05/31/91)
In article <1991May30.120936.1009@mccall.com> tp@mccall.com writes: >The routine you describe existed in the previous version of C news. It read >the Date: lines produced by dxrn just fine. BTW, dxrn isn't my software, At least get your facts straight. The previous versions of C news did not look at the date. The result was that at various times our disks filled up with news several months old. Because we complained enough the Henry and Geoff listened, and are now protecting us from these disasters. >I'm just a user. And I don't want it to fix all permutations of Date: line If you are just a user, then the important thing is to get your own Date line correct. If you are a sysadmin, just ensure that news generated on your system leaves with a correct date. Since the date should be machine generated that can't be difficult. You don't have to correct the dates generated by the rest of the world - that is their problem. >the old version just fine. I don't have a problem with switching to the >official standard, but it would've been nice to find out about it other >than by having my news articles dropped on the floor. Like maybe, before >the change was made, so I (or the author) could've fixed dxrn in advance. I believe that the intention to be strict was announced about 3 months before the changes were released. >(I don't buy the idea that nobody would have fixed the software if advance >warning were given, I know I would have fixed dxrn even if the author >didn't.) Then why didn't you? >Yep, pretty typical of the C news community. You don't give a damn what >problems you cause others, as long as your software works. Must be another The number of articles I am not seeing now is probably much less than the number dropped when disks here or on my feed filled up with stale news. >It'd sure be gratifying for someone to admit that this changeover was badly >handled. At least then we'd have some indication that a little more effort OK. I will admit it. It was handled very badly, especially by people like <tp@mccall.com>. >will be put forth next time to avoid such a mess. (I'm sure there will be a >next time, since it is C news' mission to save the world from >non-conformant software.) Actually I think C news is more interested in avoiding being the cause of the problems created by flooding the networks with stale news. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kirk@hplabs.hpl.hp.com (Laura Kirk) (05/31/91)
In article <1991May30.143123.31164@kuhub.cc.ukans.edu> sloane@kuhub.cc.ukans.edu writes: >In article <1991May30.182405.16917@mp.cs.niu.edu>, > rickert@mp.cs.niu.edu (Neil Rickert) writes: >> I believe that the intention to be strict was announced about 3 months >> before the changes were released. > >Not in any place that someone not running B or C news would be likely >to see it. Announcing a change of this magnitude should have at >least gone to all of the news.software.* groups and news.admin. I'm reasonably sure it WAS announced in news.admin: I saw it, and I don't read news.software.b (I'm a negligent news admin, I guess :-) There was a little fuss at the time, but not much. I guess the full impact didn't hit people until it happened. laura kirk kirk@hplabs.hpl.hp.com