Symlink Support

[overheadhunter]

We'd like to add createSymbolicLink(), readSymbolicLink() as well as readAttributes() with NOFOLLOW_LINKS to our CryptoFileSystemProvider.

Irregular Files

In order to support irregular files, we need to define a new type of ciphertext file. Therefore I propose the following: Ciphertext files beginning with 1 are treated as irregular files. The next character of the ciphertext file name determines the subtype. Each subtype must define how to handle it correctly.

So far the only known subtype is the symlink denoted by the subtype character S:

name prefix	example	type	subtype
0	04DNF7...3YY==	directory	-
1S	1S4DNF7...3YY==	irregular file	symlink
	4DNF7...3YY==	regular file	-

Note: The name can always be shortened, no matter if its a directory, a regular or an irregular file. The shortened name does not contain such a prefix. See name shortening specifications for further details.

Symlinks

Once we identified that a file is a symlink on the basis of its name, we need to know how its target is stored. A symlink file contains the encrypted, UTF-8-NFC-encoded target path.

The encryption is done the exact same way as for any regular file. Therefore it should be possible to remove the 1S prefix, which converts the symlink into a regular txt-file containing the path of the symlink target.