NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
In preparing to paste a code snippet, I found that this *only* happens if I include a string in the file. Here is a test function that I made, as well as an example of how I'm calling nc_open and nc_close: http://pastebin.com/63HbAWSy If I comment out either method of putting the string in there, the same thing happens, unless I comment out both methods. Variables, arrays and groups don't cause the issue. Here's a raw paste if you don't want to look at pastebin: // Test function testing strings. int rv, ncid; if(rv = nc_create(fname, NC_NETCDF4, &ncid)) goto error; // Error opening file. char *string = malloc(250); sprintf(string, "This is a string."); nc_put_att_string(ncid, NC_GLOBAL, "string1", 1, &string); char *string2 = "This is also a string"; nc_put_att_string(ncid, NC_GLOBAL, "string2", 1, &string2); free(string); nc_close(ncid); return rv; /******* nc_open call: ********/ // Open the netCDF file. if(rv = nc_open(fname, NC_NOWRITE, &ncid)) goto error; /******* nc_close call: ********/ if(ncid >= 0) nc_close(ncid); Note that I can actually read those strings or variables and attributes which are arrays of strings just fine. The only thing that causes problems is the nc_close(ncid) call, which suspends execution/crashes the program if there's a string in the file for some reason. Now that I know this, it's not such a horrible thing, since I can just store those as arrays of chars, but the string type is actually pretty convenient, so if anyone has suggestions as to how I can make it deal with the fact that strings exist, please let me know. -Paul On Mon, Aug 1, 2011 at 15:32, Kyle Shannon <ksshannon@xxxxxxxxx> wrote: > Paul, > Could you post a small example code snippet that is failing, or is it > literally nc_open() and nc_close()? > > > /** > * > * Kyle Shannon > * ksshannon@xxxxxxxxx > * > */ > > > > > On Mon, Aug 1, 2011 at 16:25, Paul Ganssle <p.g.anssle@xxxxxxxxx> wrote: > >> As a follow-up, I've spent considerable time dealing with this issue, and >> it seems like the problem is that nc_open() *always* locks files. I've >> found that if I use a debug executable or a release executable and run from >> within the LabWindows/CVI IDE, execution suspends on the nc_close() calls, >> but if I just continue execution a few times (it suspends 3 times, I >> believe), the function will finish executing and the file won't be locked >> anymore. Of course, if I run the executable from outside the IDE, it crashes >> completely. It seems like it's either a problem with nc_open or nc_close. >> Any help would be greatly appreciated. >> >> -Paul >> >> >> On Mon, Aug 1, 2011 at 13:50, Paul Ganssle <p.g.anssle@xxxxxxxxx> wrote: >> >>> Hi all, >>> I'm looking for some help with a netcdf-powered application, and it >>> seemed like this was the right mailing list to ask. Apologies in advance if >>> this is an inappropriate place to ask this question. >>> >>> >>> The problem I'm having is with the file open/close model in netcdf 4 >>> (4.1.3). I'm using LabWindows/CVI 9.0 to build a program and using netCDF >>> for all my data reading/writing needs. The problem is that in a few cases it >>> seems like I'm leaving these files open causing them to lock, but given that >>> you can't call nc_close() on a file that's been opened for reading only >>> (totally crashes my application if I do that - no error is returned), I >>> don't really understand how to unlock the files. Right now I'm dealing with >>> files where you build some set of variables and metadata in a UI editor, >>> then save them to file. If you load them from file first, when you try to >>> save them, it returns the error "Could not add HDF5 metadata", but that only >>> happens when the file is locked due to being in use, because there's a call >>> to DeleteFilename(filename) that occurs before the nc_create call. >>> >>> Given that it was only ever opened with nc_open(filename, NC_NOWRITE, >>> &ncid), I don't understand why it could possibly be locked. So my overall >>> question is, "how do I fix this?", but more specifically, I guess I'm >>> looking for a way to either force close netcdf files that were opened by >>> some unknown function or force close all open netcdf files. >>> >>> Best, >>> Paul Ganssle >>> >> >> >> _______________________________________________ >> netcdfgroup mailing list >> netcdfgroup@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ >> > >
netcdfgroup archives: