Hi Paul, re: zero-length .tmp_netcdf.xxxxxx file in /home/ldm > we can wait till you return. Until then, have a great > Thanksgiving and a safe trip overseas! I logged on this morning (while slurping my morning coffee :-) to see if I could figure out why zero-length .tmp_netdf.xxxxxx files are being created in /home/ldm... So far, I am stumped. I have verified (and re-verified) that the files in /home/ldm are being created by the GEMPAK profiler decoder, dcncprof. Why this is happening is still beyond me since the code that creates and then deletes the temporary netCDF file looks OK (/home/gempak/GEMPAK6.7.0/unidata/ldmbridge/dcncprof/dcncprof.c): the temporary netCDF file should be created in the directory in which the decoded GEMPAK file is written (/home/data/gempak/profiler). I know that a .tmp_netcdf.xxxxxx _is_ being created in the output directory; it is used to create/update the decoded GEMPAK file; and is then being deleted. The thing I can't see at the moment is why a temporary .tmp_netcdf.xxxxxx file is being created in /home/ldm AND has the same name as one being created in the GEMPAK output directory. I'll keep looking when I have a chance... Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: HVN-765439 Department: Support ldm-mcidas Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.