file://

The file scheme (file://) is intended for a standalone SpectX installation where data is accessed from the local file system. Just like the SSH scheme, it is meant for ad-hoc data analysis.

Warning

The file:// protocol method of access presents the highest possible security risk for SpectX users and their data.

Before enabling the file:// protocol please review securing local data and ensure that you fully understand the relationships and privileges between admin and user roles.

The file:// protocol provides local file and directory access to the machine acting as a SpectX host. SpectX has three configuration options for the file:// protocol:

  1. Disabled: Protocol is fully disabled to all users and processing engine. No users apart from SpectX Admins will be able to access the directory.
  2. Managed: Users with SpectX Admin privileges can open and configure access to specific folders within the directory.
  3. Unmanaged: All SpectX Users have full access to all files and folders in the host running SpectX. Only recommended for single users running SpectX on their personal computers.

Further information on how System Admins can define SpectX Admin and User file access privileges can be found in Data Access Control guide.

Using file:// in SpectX

The file:// protocol is used to access the file system on the machine acting as the SpectX host.

file:/// always refers to the root directory in the file system. However, file:///var/log/apache/access.log points to file /var/log/apache/access.log on Linux, file:///c:/Apache/logs/access.log points to file c:\Apache\logs\access.log on Windows.

To refer to data in a defined data store, its name should be used instead of a full path, like file://www-logs/access.log if there is a data store named www-logs pointing to /var/log/apache/ directory on Linux or to c:\Apache\logs\ directory on Windows.

The three slash file:/// takes the users as far up the system file hierarchy as the SpectX host system administrator login credentials permit, the entire file tree will still be visible but access will be restricted based on the files system level defined access privileges.

Once data has been added as a data store, the data store name can be used as a shortcut to that data within SpectX. For example a datastore created by directing SpectX to C:\users\admin\logs\virginia_plant\RnD\archived\logs\2019\01\january_logs.log can be named january_logs which is how it will be displayed in the resource data tree. At this point the name january_logs becomes a shortcut that can be used when working on queries in the editor pane to direct SpectX to the data, without having to input the full directory, making subsequent use of the data more efficient.

All SpectX users can now see the data store and may access any or all of the data within it that their ACL privileges allow as defined when their user accounts were created. This is particularly useful for Administrators as it allows them to securely populate their resource tree with all of the data that all levels of user need to effectively perform their duties. The ACL will then define what data if any, users can access within it. By functioning in this way administrators do not have to maintain custom users ACLs’ for all the files and folders within the directory.

Caching

Data retrieved by file:// is never cached by SpectX.

Datastore configuration

UI

Configuration parameters for file:// datastore definition:

  • Store Name - unique name among all defined DataStores. Mandatory parameter
  • Root Directory - top-level directory, the starting point for the path. It must be read accessible by the user. String. Mandatory parameter.
  • Symlinks Not Followed - tells if symbolic links must not be followed (the default) when accessing files and directories under the specified directory. Optional parameter.
  • Read ACL - specifies blob read ACL

Filesystem

file:// datastore definition file is in the JSON structure in the following format:

{
  "type": "FILE",
  "fileStore": {
    "rootDir": "<pathname>",
    "symlinksNotFollowed": <symlinksNotFollowed>,
    "acl": {<rACL>}
  }
}

where

  • <pathname> is a fully qualified pathname to a root directory of the datastore. Mandatory parameter. A string
  • <symlinksNotFollowed> tells if symbolic links must not be followed when accessing files and directories under the specified root directory. Optional. Default is “false”. A boolean (“true” or “false”)
  • <rACL> is a definition of a blob read ACL for the datastore. A map