[4205] in SIPB bug reports
Re: GRIPE about XRN 6.18beta (patch level 0)
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Oct 26 08:28:40 1993
Date: Tue, 26 Oct 1993 08:28:02 -0400
From: "Jonathan I. Kamens" <jik@security.ov.com>
To: rjbarbal@mit.edu
Cc: bug-sipb@mit.edu
In-Reply-To: <9310260224.AA07960@binkley.MIT.EDU> (rjbarbal@MIT.EDU)
From: rjbarbal@MIT.EDU
Date: Mon, 25 Oct 93 22:24:43 -0400
I am over quota.
When I enter a newsgroup I get lots of line spewed similar to the following:
> Mon Oct 25 22:18:36 1993: In newsgroup `news.answers':
> Malformed KILL file entry (pattern): ()
> --------
This appears in an "Information" popup window. I do not get this error
when I am not over quota. I have never had a kill file. Permissions on
my News subdir is fine. xrn should not complain about malformed kill files
when I don't have any. A more intelligent error message, or preferably none
at all (since it doesn't cause any problems), should appear
I can't duplicate this using the version of xrn we've got installed
here (which is very close to the one in the sipb locker) and going
over quota in a test directory.
I can't read your News directory, so I can't see if there's anything
peculiar about it that would help explain this problem. (It's also
worth mentioning that your symbolic link from
/afs/athena.mit.edu/user/r/j/rjbarbal to /afs/sipb/user/rjbarbal would
be more useful if it were a link to /afs/sipb.mit.edu/user/rjbarbal,
so that I could follow it from GZA, which doesn't have /afs/sipb but
has /afs/sipb.mit.edu.)
However, I did get another error when I tried to duplicate your
problem; perhaps the two are related. Xrn complained to me about not
being able to create a News directory, because my disk quota was
exceeded, even though one already existed. I came up with this patch,
which perhaps someone should install in the sipb locker:
*** 1.1 1993/10/26 12:09:11
--- save.c 1993/10/26 12:17:37
***************
*** 81,86 ****
--- 81,89 ----
#define BUFFER_SIZE 1024
+ #ifndef S_ISDIR
+ #define S_ISDIR(mode) (((mode) & S_IFMT) == S_IFDIR)
+ #endif
/*
* send the current article to 'command'
***************
*** 132,137 ****
--- 135,141 ----
{
static int done = 0;
char *newdir;
+ struct stat statbuf;
if (done) {
return(1);
***************
*** 140,150 ****
mesgPane(XRN_SERIOUS, "Cannot create save directory `%s'", app_resources.saveDir);
return(0);
}
! if ((mkdir(newdir, 0777) == -1) && (errno != EEXIST)) {
! mesgPane(XRN_SERIOUS, "Cannot create save directory `%s': %s",
! app_resources.saveDir, errmsg(errno));
! return(0);
}
done = 1;
app_resources.expandedSaveDir = XtNewString(newdir);
--- 144,177 ----
mesgPane(XRN_SERIOUS, "Cannot create save directory `%s'", app_resources.saveDir);
return(0);
}
! /*
! * Originally, this code did mkdir() and, if it failed, checked if
! * errno was equal to EEXIST, in order to determine whether the
! * directory already existed.
! *
! * Unfortunately, that does not always result in a correct error,
! * because (for example) in AFS, if the directory already exists
! * AND the user is over quota, then EDQUOT, rather than EEXIST,
! * gets returned. The user then gets a "Disc quota exceeded"
! * error in his message pane when there's really no reason for it.
! *
! * Yes, it might be argued that this is AFS being stupid, and that
! * it should check if the directory exists *before* it checks if
! * the user is over quota. However, unfortunately, applications
! * sometimes have to work around stupid operating system bugs.
! *
! * Therefore, I check to see if the directory exists and is a
! * directory, with stat, before calling mkdir().
! */
!
! if (! ((stat(newdir, &statbuf) == 0) && S_ISDIR(statbuf.st_mode))) {
! if ((mkdir(newdir, 0777) == -1) && (errno != EEXIST)) {
! mesgPane(XRN_SERIOUS, "Cannot create save directory `%s': %s",
! app_resources.saveDir, errmsg(errno));
! return(0);
! }
}
+
done = 1;
app_resources.expandedSaveDir = XtNewString(newdir);
I don't know if installing this will fix the problem you experienced.
jik
