Storage path

tia Content Server Core stores files like documents or metadata into the storage hierarchically.

The storage path is created by encoding of the internal path. It is then appended to the root folder to store and access data in the storage.

These configuration parameters control the storage path encoding:

These configuration values must not be changed for existing repository as it will lead to data lost and inconsistency!

Parent	Parameter	Description	Default
`<repo>.contentservice.<type>`	`contrepinpath`	When set to `true`, the storage path will always start with the repository name.	`false`
`<repo>.contentservice.<type>`	`maxfolderblocks`	create subfolder from the base32 encoded folder name with this length, this parameter can reduce the folder depth . Available values 4, 8, 16.	`8`
`<repo>.contentservice.<type>`	`maxFileNameLength`	the filename of the document encoded in base32 is maximum this long, otherwise it will be splitted in subfolders. Any number between 10 and 250 can be used.	`250`

The internal path is encoded to create the storage path by following steps:

If parameter contrepinpath is set to true, the storage path will start with the repository name.
Each directory name is Base32-encoded and the result split into blocks separately.

The block size in characters can be specified by parameter maxfolderblocks. Allowed sizes are 4, 8 (default), and 16.

Larger block size reduces the directory depth while increases the amount of sub directories inside single directory.

The component id is used as file name.

In case the length of component id exceeds the size setup by parameter maxFileNameLength, it is split into blocks of this size which get interpreted as directories with exception of the last block which is the file name. Default for maxFileNameLength is 250.

Example: Storage path for component id data of document id 0123456789ABCDEF0123456789ABCDEF.

First part for ArchiveLink repository storage path is always: Knowledge Provider/ArchiveLink.

After base32-encoding and splitting, this is:

Using a block size of 4 characters:

`Knowledge Provider`		`ArchiveLink`

`Knowledge Provider`		`ArchiveLink`
`JNXG\653M\MVSG\OZJA\KBZG\65TJ\MRSX\E`	`\`	`IFZG\G2DJ\OZSU\Y2LO\NM`

Using a block size of 8 characters:

JNXG653M\MVSGOZJA\KBZG65TJ\MRSXE

\

IFZGG2DJ\OZSUY2LO\NM

Using a block size of 16 characters:

JNXG653MMVSGOZJA\KBZG65TJMRSX

\

IFZGG2DJOZSUY2LO\NM

Next part is the document id :

Using a block size of 4 characters:

`0123456789ABCDEF0123456789ABCDEF`

`0123456789ABCDEF0123456789ABCDEF`
`GAYT\EMZU\GU3D\OOBZ\IFBE\GRCF\IYYD\CMRT\GQ2T\MNZY\HFAU\EQ2E\IVDA`

Using a block size of 8 characters:

GAYTEMZU\GU3DOOBZ\IFBEGRCF\IYYDCMRT\GQ2TMNZY\HFAUEQ2E\IVDA

Using a block size of 16 characters:

GAYTEMZUGU3DOOBZ\IFBEGRCFIYYDCMRT\GQ2TMNZYHFAUEQ2E\IVDA

Finally, the component id data is short and used as file name:

file names MRQXIYI.Info and MRQXIYI.Data

In split file system until version 2, Base32-encoding and splitting is also applied to the component id. All blocks except the last are directories, the last block is the file name.

For example: Component Id data is getting encoded as:

Using a block size of 4 characters: Subdirectory MRQX containing files with names of IYI.Info and IYI.Data
Using a block size of 8 or 16 characters: file names MRQXIYI.Info and MRQXIYI.Data