PE> That is not C's efforts to do files, that is "C's" effort to do
 PE> directories. C does not do directories. BFN. Paul. 

 PE> But POSIX does. Like I said, opendir() and readdir() are posix.
 PE> I'll have to check on fstat(), I think it also is. BFN. Paul. 

  Yair.. but opendir() is not ansi. Great language, C is.

  I've just about reached my limit, btw. I can hear Pascal calling...

... [later]

  Well, I got qsort() working, but now my trouble is that what I think 
won't work will and what I think will work won't. I think it's trying
to tell me something.

  I use the sort() function straight of out of the box like this:

int sort((void*)a, (void*)b) {return(strcmp(char*)a,(char*)b));}

  I set up a list as an array like this...

char lne[128], LIST[128][80];

load it like this...

    n = 0;
    while (!feof(bak)) {
      fgets(lne, 80, bak);
      if (lne[0] > 32) strcpy(LIST[n++], lne);
    }

and sort it like this...

  qsort(*LIST, n, sizeof(LIST[0], sort);

  Terrific! Why do I put *LIST? What the hell does *that* mean?  LIST
is an array of 128 pointers to 128 sets of 80-long memory. Why don't I
just put LIST? Doesn't *LIST mean the dereferenced LIST? Or is LIST a
set of 128 pointers to 128 *other* pointers... to the actual memory?
That's what it seems to be... fuktifino.

  Anyway... it works like a charm and is really fast, even sorting the
whole lines. In desperation I wrote my own sort program that only did
the first 4 characters and it was much slower... BUT!!!

  What I WANT to do, is create a pointer array and allocate memory on
the heap with malloc(). Like this...

char lne[128], *LIST[512], *p;

  n = 0;
  while (!feof(bak)) {
    fgets(lne, 80, bak);
    if (lne[0] > 32) {
      p = malloc(strlen(lne));
      strcpy(p, lne);
      LIST[n++] = p;
    }

  Now LIST is a set of pointers to the actual data, but what the hell
goes in qsort()? Nothing I try works! I can't even get the width right.

  Do I have to set up another array that points to those pointers? As
usual, K&R is as clear as mud. What a paira wankers! They're so intent
on showing how clever they are that they don't bother to teach.

  BTW, the stack version does the whole thing in 200mS!

  It reads the TIC, checks the file, checks the password and access,
moves the file to the correct directory, writes the new entry, adds it
and sorts it, writes a reply and rebuilds the new FILES list all in
200mS! Jesus! And no dupes. And it's even faster in cache.

  I'm still using FILES.TXT as the template, but what I've done is
move SPECIALR to the end, and call it Area 99. I keep the Area-99
list separate, and when PST adds a file, it only sorts that. The main
body of FILES.TXT remains untouched, and the new Area-99 is just added
on the end. You can still call it Area 20 if you like, as long as you
don't mind it being on the end.

  It all works... so now I'll have a look at how long it takes to
rewrite and sort the entire list.

  And work out a way to copy/move/erase files in UNIX. Or not. I
suppose UNIX does files?

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---