[netCDF #DKW-240688]: nc_rename_var(), nc_rename_dim() bugs in netCDF4?

Yup thanks, ncrename.c is a good demo with in_grp.nc, and I've verified
nc_redef and nc_enddef aren't called.  I've simplified in_grp.nc somewhat
and the bug disappears, so I'm trying to find something simpler between
those two cases so I can see what's really required for the bug.  For
example, groups have nothing to do with it, the bug's still there when all
groups are removed.

address@hidden> wrote:

> New Client Reply: nc_rename_var(), nc_rename_dim() bugs in netCDF4?
>
>  > Nevertheless, I'd very much like to see a demo of the renaming bug
>  > that doesn't disappear when nc_redef/nc_enddef are commented out,
>  > when writing a netCDF-4 (not netCDF-4 classic model) file. Maybe
>  > using variables with more than one dimension would demonstrate the
>  > bug.
>
> The renamed variable need not have multiple dimensions.
> Here's what I have for a demo of the bug:
>
> The current snapshot of ncrename.c never calls nc_redef() or nc_enddef()
> for netCDF4 files. It produces the same problems originally reported
> when run on the attached netCDF4 file.
>
> zender@roulee:~$ ncks -H -g // -v lat -C ~/nco/data/in_grp.nc
> lat[0]=-90
> lat[1]=90
> zender@roulee:~$ ncrename -O -v lat,tal ~/nco/data/in_grp.nc ~/foo.nc
> ncrename: In total renamed 0 attributes, 0 dimensions, 0 groups, and 1
> variable
> zender@roulee:~$ ncks -H -g // -v tal -C ~/foo.nc
> lat[0] tal[0]=9.96921e+36
> lat[1] tal[1]=9.96921e+36
>
> --
> Charlie Zender, Earth System Sci. & Computer Sci.
> University of California, Irvine 949-891-2429 )'(
>
>
>
> Ticket Details
> ===================
> Ticket ID: DKW-240688
> Department: Support netCDF
> Priority: Normal
> Status: Open
> Link:
> https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=24602
>



Ticket Details
===================
Ticket ID: DKW-240688
Department: Support netCDF
Priority: Normal
Status: Open