The standard provides no method for a client to discover the list of files in a server.
7-2 Clause 7.2.2.3.1 declares that GetServerDirectory(file-system) returns "the file name(s) present in the file system".
8-1 clause 9.3 declares that GetServerDirectory(FILE) has an optional constraint of "the name of a File in the FileSystem" with defined options of the constrainst being absent or "*" or "/" or "\" which are all equivalent and "shall return, at a minimum, the Filenames present in the root directory (additional file may also be returned)." Note that this contradicts the conformance statmenet table 127 (Clause 24.2.2.4.2)
8-1 Clause 23.1 specifies that MMS file path is a sequence of file directory names separated by "separator". It further recommends that filenames which represent directories should end with a separator.
This combination of standards makes it impossible to a client to obtain a list of all files exposed by the IEC 61850 filesystem.
It also does not take into account the common situation where a client requests a list of filenames within a specific directory.
Proposal
1. In Clause 9.3, remove the optionality of the FileSpecification parameter to FileDirectory.
2. In Clause 9.3, re-define the 8-1 GetServerDirectory(FILE) mapping to include all "IEC 61850-exposed" files with all 4 defined constainsts. Note that this is somewhat in contradiction with the existing statement "The names of the files returned shall be the filenames of the files present in the LD directory".
3. Add to Clause 9.3 "The list of files shall include the names of directories (in other words, the filename "COMTRADE/" should be returned by most servers)."
4. Recommend that that returned filenames not begin with a separator (to conserve the name length)
5. In Clause 23.1, change the recommendation that filenames representing folder names end with a separator to a requirement
6. Change Table 35 constraint from "File is the name of a File in the FileSystem" to "File is the name of a File in the FileSystem if the name does not end with a separator or the name of a directory if it ends with a separator. If a directory name is used, the listOfDirectoryEntry shall consist only of the filenames which start with the name of the directory; the list shall not include the entry consisting of only the directory name)".
Discussion
Created
Status
Final change: Clause 9-3 - FileClass:
Remove "at a minimum". The correct sentence shall be:
If the Filename (for instance MMS FileSpecification) is not present in the FileDirectory.request, or if the wildcard ‘*’ character is used, then the responding server shall return the Filenames present in virtual fileStore.
03 Feb 14
In Force (green)
In regards to 1):
First 8-1 is specific to MMS/GOOSE and not ACSI. Therefore, parameters that are needed for the MMS file service are IN SCOPE of 8-1 even though they are not in 7-2. It is worthwhile to note that FileName is an ACSI parameter in ACSI (look in 20.1 of ED.1 and 23 of ED.2). The GetServerDirectory service in 7-2, references the File class and really is intended to return all files. So, 7-2 has not concepts of a file directory structure or wildcards. Thus, any extensions, and the mapping of filename is clearly an 8-1/MMS issue.
ISO 9506-1 (Services) for FileDirectory does not have a concept of a directory, but does acknowledge “file groupings” and “wildcards”, these the actual specification of the syntax for these is outside the scope of 9506. But the FileNames returned by a directory response must be unique FileNames that can be used directly in a FileOpen request. Therefore, incomplete groups and wildards can’t be returned in a FileDirectory-response.
The proper way to specify to return all files, for MMS in a directory response is to not specify a FileSpecification in the request and mandate that the “default” group for 61850 compliant devices are all
files within the 61850 virtual filestore.
Therefore, I agree with Thierry.
In regards to 5:
It is my belief that a FileSpecification of “COMTRADE” should not return anything since it is not a “File” that can be opened by a FileOpen-request.
Therefore, I agree with Thierry.
I do not believe any change is required.
14 Jun 13
Ballot Period
1) Agree with Thierry that fileSpecification parameter can remain optional. But note that "Filename" is not an ACSI service parameter; but is an extension to ACSI defined by 8-1. Also, clause 9.3 is not clear that the wildcard character is used in the MMS parameter fileSpecification and not the parameter continueAfter. Also should add definition of the MMS response if the MMS fileSpecification parameter is other than "*" or separator. I suggest "If the fileSpecification parameter is not "*" or the separator then the server shall return all Filenames in the virtual fileStore whose names begin with the the fileSpecification parameter. Notes that if names in the directory response begin with a separator and fileSpecification does not begin with a separator then an empty list shall be returned."
2) I agree with Thierry's recommendation to remove "at a minimum" from clause 9.3
3)Upon further review, now I think that the file list should not contain the names of only directories. These "filenames" cannot passed to FileOpen and are thus useless.
4) I disagree with Thierry because the "root" of the filestore is a property of the MMS connection and all filenames MUST begin at the "root". I see no value in wasting bandwidth transmitting a beginning separator character. It can only lead to implementors pondering the difference between "COMTRADE/xxx" and "/COMTRADE/xxx". A filestore name which begins with a separator also violates part 7-2 clause 23.1.1 defining the syntax of a FileName (which only allows the SCSM to make restrictions and not extensions to the syntax)
5) A fileDirectory request for "COMTRADE" returns both "COMTRADEFILE" and COMTRADE/myfile.zip whereas "COMTRADE/" returns only the latter filename.
6) Table 35 is confusing. The constraint for continueAfter should be "the final entry of listOfDirectoryEntry in the response to the previous FileDirectory-Response if that indicated "moreFollows", otherwise the parameter is not present"
14 Mar 13
Ballot Period
I agree
07 Mar 13
Ballot Period
1) I disagree - the file specification "*", "/", "\" are all equivalent and specify root. They are identical to "no file specification", which is what 7-2 is defining
2) I do not see anything as such in 9.3. So I can not find a contradiction here. The 61850 virtual filestore only exposes files that are available via 61850. Other files may exist but may not be exposed through the virtual filestore.
3) The note is not necessary since 23.1 defines. The path specification is Mandatory already!
4) I disagree. "/" stands for ROOT and therefore enforces that the path is absolut, i.e. starting from root. I would on the contrary recommend that it should start with a separator!
Additionally, based upon an issue from the last IOP, the GetFile.request must pass in exactly what the client received in the fileDirectory.response. Therefore, it does not matter, as it is an issue of the VirtualFileStore path construction that is mandatory per 23.1 “The MMS virtual file store path specification is mandatory in the File name.”
5) since fileDirectory.repsonse (ListOfDirectoryEntries) is determined by the file specfication passed in the fileDirectory.request, there is no difference between COMTRADE or COMTRADE/
no change is needed.
6) Not accepted. Table 35 specifies the continue after. ContinueAfter does not limit the scope of the response. The response is limited by the initial fileSpecification in the fileDirectory.request.
Final Proposal: Clause 9-3 - FileClass
Remove "at a minimum". The correct sentence shall be:
If the Filename (for instance MMS FileSpecification) is not present in the FileDirectory.request, or if the
wildcard ‘*’ character is used, then the responding server shall return the Filenames present in virtual fileStore.