20020104: servutil.c in sdi library

>From:  Scott Lindstrom <address@hidden>
>Organization:  Space Science and Engineering Center
>Keywords:  200201041558.g04FwHN15124 McIDAS-X servutil

Scott,

>Tom, I have a couple questions about a function in servutil.c
>that is perplexing me in its behavior.  I'm using servutil.c
>in the level 1b server, and I know it's also in the nexrad
>server, which you wrote, so that's why I'm sending this
>email to you :)

I also use it in my GINI and WSI NOWrad (tm) servers.

>In the module PushFileByName, why call Mcbasename in the strcmp
>call in the while (1) loop that finds where the file
>name should be ordered?

This is kind of a historic artifact that was not changed since it
seemed to have no ill effects.

>On popeye at least, that is returning null strings.

It shouldn't if the string passed to it is properly formed.
As I read the code in Mcbasename.c, the only way a NULL could be
returned is if the input string is a NULL pointer or if the
first character of the string is a NULL.

>And at least in the level 1b
>server, the name is fully resolved at that point anyway.
>I'd yank it, but I don't know how important it is for
>the nexrad server.  

Yank what?  Do you mean do the comparison between the full pathname and
not the actual file name?  This may be OK, and it would seem like it
would allow for files of the same names in different directories being
both included in the list.

>Also, in GetFileList, there is code that appends a '/'
>to the file name if it doesn't end in a '/'.

The code appends a '/' to the directory name if it doesn't exist.
I wrote the code to allow for the directory and file names to be
specified separately:

DIRMASK=/blah/blah/woof/*
FILEMASK=woof*

These get fused together into a fully qualified pathname like:

/blah/blah/woof/*/woof*

The '/' was needed at the end of the DIRMASK= value in order to create
the fully qualified pathname.

The approach taken at SSEC was to be able to specify a mask for
the fully qualified pathname:

DIRFILE=/blah/blah/woof/*/woof*

>Wouldn't
>this mean that a filemask could not include a file
>name.

In my case it did.  My NEXRAD Level III (and GINI and NOWrad) server
allows for specification of DIRFILE= in addition to the DIRMASK=
and FILEMASK= values from a configuration file.

>Well, it could, but GetFileList would change it
>to a directory.

It doesn't in the NEXRAD server since I split the DIRFILE= value
back into a DIRMASK= and FILEMASK= value before calling GetFileList.

>IN my example, dsserve's mask is
>/home/scottl/mcidas/data/l1b/*.10bit, to differentiate
>from all the 16bit data in that particular directory.

For my GetFileList to work, I would break this into

DIRMASK=/home/scottl/mcidas/data/l1b
FILEMASK=*.10bit

The code in GetFileList then does the work of reassembling this:

    /*
    ** Create the space for the file name mask
    */

    len  = strlen(request->dirmask) + strlen(request->filemask) + 2;
    len += MAX_TOK_LEN * NumToken(request->dirmask);
    len += MAX_TOK_LEN * NumToken(request->filemask);

    filename = malloc( len );
    if ( filename == (char *) NULL ) {
      M0sxtrce( "GetFileList:: error mallocing filename" );
      return FAILURE;
    }

    p = request->dirmask + strlen(request->dirmask) - 1;

    (void) strcpy( filename, request->dirmask );
    if ( *p != '/' ) {
      (void) strcat( filename, "/" );
    }
    (void) strcat( filename, request->filemask );

>But GetFileList makes a file name with a '/' following
>the 10bit, and I'm not sure why.

This is one of those backward compatibility issues.

>If you can provide any insight, I'd appreciate it.

Let me know if the above doesn't make sense.

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+