This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Organization: National Energy Research Supercomputer Center (NERSC) > Keywords: 199402081848.AA23753 HPUX ncredef Chris, Thanks for the bug report. Though I had to correct a couple of problems in your test program, it definitely does demonstrate a netCDF bug on HPUX systems that I hadn't seen before. There is an error in the argument type for the fifth argument to ncvardef() in both calls in your test program. The argument must be the address of an array of (in this case only one) dimension id(s), not the value of the dimension id. Therefore the argument in each case must be "&dimid" rather than "dimid". I've inserted the corrected statements in the source to the test program below: > cc ntest.c -g -I/path/to/netcdf/includes -L/path/to/netcdf/libs \ > -lnetcdf -o ntest > ------------------------ cut here ------------------------------------ > /* file ntest.c */ > #include <stdio.h> > #include "netcdf.h" > float var1[]={0.,1.,2.,3.}; > float var2[]={3.,2.,1.,0.}; > main(argc,argv) > int argc; char *argv[]; > { > int cfid,dimid,var1id,var2id; > long start=0,count=4; > ncopts=NC_VERBOSE; > if((cfid=nccreate(argv[1],NC_NOCLOBBER))== -1) { > fprintf(stderr,"Can't create NetCDF file %s\n",argv[1]); > exit(1); > } > if((dimid=ncdimdef(cfid,"Dim1",4l)) == -1) { > fprintf(stderr,"Can't create Dim1\n"); > exit(1); > } > if((var1id=ncvardef(cfid,"Var1",NC_FLOAT,1,dimid)) == -1) { if((var1id=ncvardef(cfid,"Var1",NC_FLOAT,1,&dimid)) == -1) { > fprintf(stderr,"Can't create variable 1\n"); > exit(1); > } > if(ncendef(cfid) == -1) { > fprintf(stderr,"Can't end first definition\n"); > exit(1); > } > if(ncvarput(cfid,var1id,&start,&count,var1) == -1 ) { > fprintf(stderr,"Can't write variable 1\n"); > exit(1); > } > if(ncredef(cfid) == -1 ) { > fprintf(stderr,"Can't re-define NetCDF file\n"); > exit(1); > } > if((var2id=ncvardef(cfid,"Var2",NC_FLOAT,1,dimid)) == -1) { if((var2id=ncvardef(cfid,"Var2",NC_FLOAT,1,&dimid)) == -1) { > fprintf(stderr,"Can't create variable 2\n"); > exit(1); > } > if(ncendef(cfid) == -1) { > fprintf(stderr,"Can't end second definition\n"); > exit(1); > } > if(ncvarput(cfid,var2id,&start,&count,var2) == -1 ) { > fprintf(stderr,"Can't write variable 2\n"); > exit(1); > } > if(ncclose(cfid) == -1) { > fprintf(stderr,"Can't close NetCDF file\n"); > exit(1); > } > printf("Wrote file OK\n"); > } > -------------------------------- cut here ----------------------------- With the indicated corrections, this compiles and links OK. > Compile and load this program in some directory, then run 'ntest file.nc' > then 'ncdump file.nc'. It should look like > netcdf file { > dimensions: > Dim1 = 4 ; > > variables: > float Var1(Dim1) ; > float Var2(Dim1) ; > > data: > > Var1 = 0 , 1 , 2 , 3 ; > > Var2 = 3 , 2 , 1 , 0 ; > } Yup, this looks OK. > Here's where I get in trouble: > say 'ntest' is in my home directory. > 1. Try this: > cd /usr ( or some directory you don't have write access to) > ~/ntest ~/file.nc > I get the following messages: > > ncredef: filename "aaaa0963": Permission denied > Can't re-define NetCDF file > > I believe that this shows how NetCDF is trying to create a scratch file > in the current working directory (/usr in this example). A scenario where > this might occur would be if you are sitting in someone's directory reading > files, and trying to create files in some other directory. OK, I get a similar, though not identical error on HPUX 9.01: % cd /usr % ~/ntest ~/file.nc ncredef: filename "": No such file or directory This definitely demonstrates a bug on HPUX, since the same thing works OK on other platforms. Thanks for the bug report. We'll put this on our list of things to fix. I'm pretty sure the cause of the bug has nothing to do with permission to write in the current working directory though, because I get the same thing if I first change to a different writable directory, say ~/test: % mkdir ~/test % cd ~/test % rm ~/file.nc ; ~/ntest ~/file.nc ncredef: filename "": No such file or directory Can't re-define NetCDF file This also indicates a deficiency in our nctest testing program, since it does all its ncredef() calls in the same directory, so it never catches this bug. > 2. The thing with the FILENAME_MAX might be harder to re-produce on your > HP system. On ours, we have our home directory in AFS, and then a work > directory on the system. For example, my work directory is /work2/u70177. > if 'ntest' is actually '/work2/u70177/ntest' I try this: > > /work2/u70177/ntest /work2/u70177/file.nc > ncendef: rename failed: Is a directory > Can't end second definition > > If you can somehow reproduce this on your HP system by creating a few > subdirectories I believe you will see these results. We don't have AFS and I can't reproduce this. > >......We can't > >change the behavior of the netCDF library on other systems to work around an > >HPUX bug, but perhaps we should provide a special case in libsrc/local_nc.h > >that redefines FILENAME_MAX as 255 for HPUX. I'll look at that when we test > >the next release on HPUX. > > Here's HP's response to my message querying them about FILENAME_MAX: > > >You are correct in that FILENAME_MAX is defined to be 14. However, you > >probably should be using MAXNAMLEN as it is ansi compliant. It is > >defined in ndir.h as well as a few other header files. If you cannot use > >another constant, then you may consider creating a user header file to > >be included with your application that sets FILENAME_MAX to 255. > > This will cause warning messages saying 'redefinition of FILENAME_MAX' > to come out, but seems to work otherwise. I will patch this on our HP for now. __________________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden P.O. Box 3000 (303)497-8645 Boulder, Colorado 80307-3000