Mostly done.

1. specification did not have anything about exceptions. Added small comment to doxy
2. Only checks if target link already exists. Should we also check if original path exists or target parent exists? What does the C API check in order to return failure? There seems to be little of these details documented, but this seems a good question to ask, since we may be performing redundant checks. Maybe there is a better way to find out other than by testing every case?
3. The C API docs say " Furthermore, if the object pointed to by the original link was already open with a valid object identifier, that identifier will remain valid after the call to H5Lmove." This raises the interesting question of whether the original node object ought to be modified in the process? Similarly, should removing a node invalidate it somehow?

from h5cpp.

on 2

I would say that we definitely have to check if the original link exists. Otherwise there is nothing to move. For the new link the situation is a bit more tricky

• we have to check whether it already exists or not. If it does this would be an error.
• if it does not exist the situation depends on the configuration of the link creation property list. If the
  create intermediate groups flag is set we have to do nothing as the library will automatically create
  missing groups. If the flag is not set I expect the library to return an error for this operation.

on 3

I guess this is the really difficult task. We would have to notify an already open object (we could identify it via its id()) that its path has changed. However, this is only necessary if the path we want to move was the path used to open the object (it could have been accessed via an alternative route). As a matter of fact this would be an interesting use case for our central object registry in the context. The procedure would maybe look somehow like this

1. find all open instances of a node referenced by the path we want to move (look for ID)
2. within this set we have to find all instances which have used the very path we want to move
   to access the node
3. we have to change all the paths for these nodes to the new path once the move was successful.

This would be pretty cool but is also rather complex to implement (requires quite some infrastructure). So I would actually fix 2 and live for now with the fact that there might be object which have the wrong path within their link. However, we should definitely move the above procedure described in 3 to a new ticket and thus keep it as a good use case for a central node registry.

from h5cpp.

Q2: deferred for development of better tests in #36
Q3: created new ticket for this #39
Closing this

from h5cpp.