Skip to content

DMS Browser

The DMS browser shows what is actually stored on disk — pick a storage location, click through the directories, open the files. It lives at /v2/admin/files in the DMS Browser tab (permission file_administrator_options).

The usage card in the File Storage tab next to it answers "how full is it"; this tab answers "what is in there".

Storage locations

Location What lives there Configuration
Documents (DMS) The stored documents, organised by version chain DMS_PATH / DMS_STORAGE_MODE
Inbox The watched folders per file type, plus _archive with the imported originals DMS_INBOX_PATH
File manager The tree outside the DMS, written by calServer V1 and WebDAV FILEMANAGER_PATH

Each location shows the path the server actually uses. In a fault that is the decisive detail: an empty listing means either "nothing stored" or "wrong tree", and the path tells you which.

Storage mode v1-tree

When calServer V2 continues the V1 tree (DMS_STORAGE_MODE=v1-tree), the DMS storage lives inside the file manager tree. Both locations then point into the same directory tree; the browser says so.

How the DMS storage is laid out

The DMS storage is not organised into human-readable folders but by version chain:

{DMS storage}/{hash}/{major}_{minor}/{hash}.{extension}
  • The hash folder groups every version of one document. The browser looks up the document name and puts it first; the technical name stays underneath, because that is the one in the file system and in the server log.
  • The version folder 1_0 is version 1.0 and is shown as such.
  • With hash-prefix sharding enabled there are two more levels in front (ab/3x/…) to keep the number of entries per directory small.

A hash folder without a record stays visible and without a document name — it is a leftover. The opposite case, a record without a folder, shows up in document management, not here: a directory browser cannot show what does not exist.

Why the browser only reads

Unlike calServer V1 (elFinder with upload, rename, delete) this view is read-only. Three reasons, any one of them sufficient:

  1. The handover point is the inbox. Files arrive through a watched folder and are versioned and released there. A browser that may drop files anywhere in the tree would be the way around that — producing documents without a version and without a release.
  2. The file manager tree belongs to V1. In storage mode own it is mounted read-only in the API container on purpose.
  3. Renaming would make documents unfindable. File names in the DMS storage are keys, not labels; the database would never learn about a change.

Misfiled files are therefore still corrected in the inbox — rename within the same folder, or move to the right watched folder, both before the import.

What you can do here

  • Open a directory — click the row or the folder icon; the breadcrumbs at the top lead back.
  • Download a file — delivers the file exactly as it lies on disk, without the version and release detour of the document list. That is the point: see what was really stored.
  • Jump to the document — where a record backs a file or hash folder, the arrow opens its detail page.

Large directories

The first 500 entries per directory are listed; beyond that the browser flags the listing as truncated. A grown DMS storage holds more than a list can usefully carry — use the filters in document management to find a specific document.