Symantec Developer Group

 View Only

EV Filtering API & Third Party Classification API

  • 1.  EV Filtering API & Third Party Classification API

    Posted Feb 27, 2014 10:40 AM

    Software:

    • Symantec Enterprise Vault. Version: 10.0.4.1189
    • Symantec Enterprise Vault FSA Agent (x64). Version: 10.0.4.1189
    • Symantec Enterprise Vault Filtering API.
    • Third Party Classification SDK.

    Description:

    Using the Filtering API to create a custom filter, the filter will communicate with a third party classification API; during the ProcessFilter method. During each ProcessFilter call the full path of the item that is currently being processed should be passed into the third party API call. The third party API will use the full path of the item/file to read metadata that has been associated with that item. The third party API call will return a dictionary list of values. The third party software appends metadata to files by attaching a separate file, as an alternate data stream; fork. This is the metadata that needs extraction.

    Problem:

    1. During each ProcessFilter method access to the absolute path of the item/file being archived is needed; not just the file name. As the third party API call requires a full path to the file to properly return metadata values. So far unable to find a way to obtain the absolute path from the IArchivingControl or IFileArchivingControl.

    Attempts:

    1. Although System.IO.Path.GetFullPath() does return an absolute path. It returns an absolute path to the file based on where it is located on the file server. The Enterprise Vault server processing the filter cannot access the item with this path for obvious reasons. An alternative would be to use a UNC path.
      1. Using a hardcoded UNC path does allow the third party API call to function moderately properly. However, there does not appear to be a concise way to generate or obtain a UNC path. Furthermore, the third party API does not read metadata from certain file extensions properly when using a UNC path.
    2. Passing in IFileArchivingControl.Name fails, as the third party API call requires the full path to the file.
    3. Third party metadata can be accessed through the IFileArchivingControl.OpenStream method, however it returns the data in XML format. The third party API call will parse the metadata accordingly and return it as a dictionary value.
    4. Casting the Stream object generated from either the IFileArchivingControl.Open or IFileArchivingControl.OpenStream methods to a FileSteam object and attempting to access the FileStream.Name property simply returns “[Unknown]”. Therefore, using the file stream name to access the file is futile.

    Questions:

    1. Does the ProcessFilter method of the Filtering API have anyway to access the full path of the  item/file being processed? Not just the item’s file name?
      1. If so, what will the path look like? And how is it accessed?
      2. Will this be possible without using a UNC path?
    2. Granted the third party metadata can be accessed through the OpenStream method, the attempt to avoid replicating what the third party API already does seems imperative, is this pattern how most third party classification API seem to function? How is metadata normally accessed through third party API?