Issues with Creating a Function That Returns the Name of A Dereferenced Object: -------------------------------------------------------- When we store an object, we do not store the path in the object header. It means that when we have a reference (and reference is created from the absolute address of the object in the file), we can open the object without knowing the path to it. Since we know from the reference the address of the object, we can do the following to find paths to it: start from the root and iterate over each group; while iterating, get names from the group's symbol tables, and also get objects addresses from a group's B-tree; compare the address of our object with the one returned by the iterate procedure until the object is found. What we find, may be just one of the existing paths to the object. Therefore, even if we found one, we have to iterate further to find all existing ones (dealing with loops in general case, etc.) We have to build a "table of content" for the file at least once and keep it in memory for each H5Rget_obj_path call (memory concerns and other efficiency and maintenance issues such as when to update the table and who closes it, how to search it quickly, etc). Obviously it is not efficient to build the table every time you call H5Rget_obj_path. The table has to be attached to a file id in order to deal with multiple opened files. Also what should we do with the file opened several times? As you can guess there is not simple, efficient and clean solution. That is why developers have been so reluctant to implement it.