Log In
Home
07/18/2020
Offline
Hello,
I have some questions about file system representation in a server using FileType and FileDirectoryType according to Part 5 Annex C and symbolic links (on a Linux system) as I could not yet find some more details in the specification.
There are several options how a symbolic link to an element could be represented, two examples are below:
1: Treat a symbolic link (and all elements below in case of a directory) like a normal individual node in the address space. So it is not visible that the node represents a linked element. Every element that can be reached from the link gets a new node instance.
But this leads to the next questions like how to handle the OpenCount of a file: Should the OpenCount be synchronized between all FileType instances representing the same file?
Another topic is related to the possibility of creating circles: Every file system element (file or directory) is added with an Organized reference below an instance of FileDirectoryType. As far as I know circles created with hierarchical references are forbidden within a servers address space. In general on a file system it is possible to create circles using symbolic links. With this approach it would lead to an endless deep structure in the address space. (Needs presumably be detected by the server implementation and stopped somehow.)
2: As hierarchical references can not be used in all cases: Use another not hierarchical reference type to connect the parent node/directory of the symbolic link and the (already existing) node representing the destination of the link. This would solve the possible issues of several nodes representing one file or hierarchical circles. But as it is a custom solution it can presumably not be handled by all client implementations accordingly.
I had a look at the file access facet related test cases, but it seems that they are not formulated yet. Have topics like this maybe been addressed already somewhere else?
It is possible to create a custom solution for file system related topics like symbolic links, but I think that it would be good to have some best practices how to handle them (even if it can or will not be specified). This would presumably simplify client implementation as they do not need to handle several different solutions from different servers. Are there maybe plans to create such hints for implementing file system access via OPC UA?
Thank you.
05/30/2017
Offline
Use references.
The same FileType Object can be the target of Organizes references from many FileDirectoryType Objects.
Any symbolic link would be replaced with a reference to the real FileType Object.
This eliminates any questions about OpenCount etc. because there is only one Node that is accessible via multiple paths.
07/18/2020
Offline
Thanks for the quick reply.
In case a file is the target of the symbolic link, your solution is the best choice. I agree. The hierarchical Organizes reference can be used like for every normal file located in the directory. (And it solves several problems when multiple nodes would represent one file.)
But there is still the hierarchical circle aspect when the target of the symbolic link is a directory: It may not happen very often but it is possible to create circles in the file system using symbolic links to directories. If Organizes is also used to refer to the target directory of the symbolic link, it could result in hierarchical circles in the address space. That was the reason why I wrote about using a not hierarchical reference.
1 Guest(s)
Usage Policy