User Tools

Site Tools


accessing_data_on_a_network

This is an old revision of the document!


Accessing data on a network

It is very possible that WSI data is not stored on the local drive, but on a shared (high-capacity) storage device. There are several reasons why this may be the case:

  • Unordered List ItemThis machine may collect files from different locations and/or scanners.
  • Unordered List ItemThe system requirements for your file server may also vary significantly from the requirements of PMA.core.
  • Unordered List ItemLast but not least, you may simply want to access data for a temporary project that's stored somewhere else at your company or institute, without having to go through the trouble of copying several terabytes of data.

PMA.core therefore lets your map root-directories on a (shared) network drive. A UNC-path to a networked directory looks like \\servername\sharename\dir\subdir\. There are three conditions for this:

  • Unordered List ItemThe UNC share must exist at the time of creation
  • Unordered List ItemThe IIS account running PMA.core must have sufficient access rights to the specified path
  • Unordered List ItemThe share may not be accessed through a mapped drive; but only through a fully qualified UNC path

If no immediate access is possible for the share, you may specify impersonation information (which should be provided to you by the system administrator who's responsible for the machine that you're trying to reach). Impersonation information is verified, and the root-directory may only be created if impersonation is successful.

You must specify a domain. If no domain-name was given to you (e.g. on a Samba-share), you may enter “.” as a default domain.

When a UNC share does not exist, the following error message is displayed:

Note that you can only map network locations through their UNC path. PMA.core does not allow mapped (network) drives to be referenced directly. If \\servername\sharename\ is mapped as drive X:, you can not create a root directory with the path reference x:\dir\subdir\. The reason for this is twofold:

  • Unordered List ItemA file needs to be traceable to an unambiguous location. There's no way to find out whether \\servername\sharename\dir\subdir\foo.svs and x:\dir\subdir\foo.svs are the same files (at least not in a simple straightforward manner)
  • Unordered List ItemSince IIS runs as a background service in the OS, it cannot be guaranteed that the x: drive-letter will always be available (especially when no actual user is logged into the system).
accessing_data_on_a_network.1591091835.txt.gz · Last modified: 2020/06/02 12:57 by charlotte