linked-to file close

Hdf-forum archives
1

Hi all,

I came into an issue I cannot understand, I need a piece of advice... (HDF5 1.8.8 x86 platform)

I open a file, say TOP.hdf, (read mode but it looks it has no effect), this file
contains external link, say SUB*.hdf.
The TOP is open with a strong close degree, which means we affect the file access
property list. The links also have their own property list, and then in both parent
and child files we have non-default properties (and we do not use external link callbacks).

As I understand the docs, the properties of the parent should be propagated to the children files,
but it looks the close degree is not:

I open the TOP.hdf file, I close it
I open the SUB.hdf file, HDF5 error (in the close degree comparison while opening the file):

#### DBG [ 1914] ADFH_Database_Open [SUB.cgns]
HDF open [SUB.cgns]
HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
   #000: H5F.c line 1522 in H5Fopen(): unable to open file
     major: File accessability
     minor: Unable to open file
   #001: H5F.c line 1342 in H5F_open(): file close degree doesn't match
     major: File accessability
     minor: Unable to initialize object

It looks that closing the TOP.hdf file doesn't close the SUB.hdf file.
When I trace the HDF5 calls, we actually have a single open/close on the TOP file
and no other access to SUB.hdf except through link traversals.

Then 2 (main) questions:

1- is it possible the SUB file stays open even if we close the TOP file?
    is there an HDF5 call I could use to test this?
2- if the SUB file is still open, it should be shared and then why does it
    fail on the close degree comparison?
    should we use a callback to force linked_to file close degree to STRONG?
    is the close degree difference between TOP and SUB a possible reason for
    the non-propagation of the TOP close?

Source code too big to be attached.

-MP-

···

-----------------------------------------------------------------------
  Marc POINOT [ONERA/DSNA] Tel:+33.1.46.73.42.84 Fax:+33.1.46.73.41.66
  Avertissement/disclaimer http://www.onera.fr/onera-en/emails-terms

2

There is a test case that reproduces the error we have.
Certainly I'm using the prop API the wrong way...

---- tlinks.c file
/*
   cc -I/usr/local/hdf5-1.8.8/include -c tlinks.c
   cc -o tlinks tlinks.o -L/usr/local/hdf5-1.8.8/lib -lhdf5
   ./tlinks
*/

#include "hdf5.h"

int main(int argc, char **argv)
{

   hid_t fcpl,fapl,lapl,tfid,sfid;

   fcpl=H5Pcreate(H5P_FILE_CREATE);
   H5Pset_link_creation_order(fcpl,H5P_CRT_ORDER_TRACKED|H5P_CRT_ORDER_INDEXED);

   fapl=H5Pcreate(H5P_FILE_ACCESS);
   H5Pset_fclose_degree(fapl, H5F_CLOSE_STRONG);

   lapl=H5Pcreate(H5P_LINK_ACCESS);
   H5Pset_nlinks(lapl, 7);
   tfid=H5Fcreate("TOP.hdf", H5F_ACC_TRUNC, fcpl, fapl);
   H5Fclose(tfid);

   sfid=H5Fcreate("SUB.hdf", H5F_ACC_TRUNC, H5P_DEFAULT, H5P_DEFAULT);
   H5Gcreate(sfid, "ROOT SUB", H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT);
   H5Fclose(sfid);

   tfid=H5Fopen("TOP.hdf", H5F_ACC_RDWR, fapl);
   H5Gcreate(tfid, "ROOT TOP", H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT);
   H5Lcreate_external("SUB.hdf","ROOT SUB",tfid,"SUB",H5P_DEFAULT,lapl);
   H5Fclose(tfid);

   tfid=H5Fopen("TOP.hdf", H5F_ACC_RDONLY, fapl);
   H5Fclose(tfid);

   sfid=H5Fopen("SUB.hdf", H5F_ACC_RDONLY, fapl);
   H5Fclose(sfid);
}

···

----

-MP-
-----------------------------------------------------------------------
  Marc POINOT [ONERA/DSNA] Tel:+33.1.46.73.42.84 Fax:+33.1.46.73.41.66
  Avertissement/disclaimer http://www.onera.fr/onera-en/emails-terms

3

I finally found something (btw the test I've send did not reproduce the bug,
if you set the same fapl in both file creation/open there is no problem).

My application runs correctly with the following patch, please let me know
if this shows an actual problem or if its related to my own application...

I was tracking the fc_degree, which was changing at insertion time in H5Fsfile.c
and then was leading to an error in H5F.c/H5Fopen/H5F_open). I found the
fc_degree was not updated in H5F.c/H5F_new, which was the caller of 5Fsfile.c/H5F_sfile_add.

The brute force solution is to set the fc_degree at this place...
Again, I'm not able to write a test case reproducing the problem.
Anyway, my application now works :wink:

--- src/H5F.c 2011-11-07 23:11:30.000000000 +0100
+++ src/H5F.c.modif 2012-05-24 17:28:06.000000000 +0200
@@ -832,6 +832,7 @@
  H5F_new(H5F_file_t *shared, hid_t fcpl_id, hid_t fapl_id, H5FD_t *lf)
  {
      H5F_t *f = NULL, *ret_value;
+ H5F_close_degree_t fc_degree;

      FUNC_ENTER_NOAPI_NOINIT(H5F_new)

@@ -949,6 +950,8 @@
             HGOTO_ERROR(H5E_FILE, H5E_CANTINIT, NULL, "unable to append to list of open files")
      } /* end else */

+ H5Pget_fclose_degree(fapl_id,&fc_degree);
+ f->shared->fc_degree=fc_degree;
      f->shared->nrefs++;

      /* Create the file's "top open object" information */

-MP-

···

-----------------------------------------------------------------------
  Marc POINOT [ONERA/DSNA] Tel:+33.1.46.73.42.84 Fax:+33.1.46.73.41.66
  Avertissement/disclaimer http://www.onera.fr/onera-en/emails-terms