On the client host, files are organized in a different way. Like on the server folders are stored in a dedicated directory (the folder store) with their unique server side identifier as names (dirId meta value). Each of these directory stores the meta files (the files storing the headers), using the same hash for the filename that is used by mdird to send deletion patches, in order to be able to quickly find the relevant file in such occasion (SHA1 seams a good starting point since when SHA1 will be proven wrong this whole source code, being versionned with GIT, will prove unreliable). Each folder also has a special file for storing the client journal version (.seqnum), as well as a .hide file listing the subfolders the user does not want to track (as a folder may be mounted on several locations that's the parent-folder business to know if a subfolder is to be tracked)..
In addition the client also have to store some messages content in another dedicated directory, the message cache. As the name suggests this storage area serves just as a cache and any file removed from there will be automatically downloaded again by the library when requested. Files are stored here under their URL as a name, sub-directories being created as required, for it's convenient both for the program and the user.
The two previous directories were not intended for direct examination for the end users, and may be hidden anywhere. A user oriented classical file system may be achieved, for instance from a given subfolder, with the help of a proper plugin for file sharing. This is briefly explaned here for completeness (and because the client library was designed in order to make this plugin possible), but really belongs to the plugins section. In this mdir mount point the message contents will be hardlinked with a unique but nonetheless meaningful name, each directory being a symbolic link to the corresponding folder in the folder store named with the folder's user name (the name meta value).
These meaningfull names will use the meta suggested file name or any other apropriate meta field, using numerical prefix to disambiguate the names (how to construct the new name may depends on the filesystem - some may even support version number ?)
Why the server itself does not dicates these filenames ? First because the server can't know if these names are required. Then because the server don't know of various specific constraints for the filesystems that reign on its client, nor the local conventions for generating unique file names (some filesystems may even handle versionning ?). Notice that a file may appear with different version numbers on distinct folders which is very unpleasing - but that having the server dictates the names will not help here. If the version number gets irritatedly wrong sometime it's still possible to reset the directory somehow.
So now the user can have a plain directory hierarchy with ordinary files to play with. Let's see what happen if he ...
For the mdird client, adding a message is just adding the meta file. The user has to fetch it to download the content and link from the mdir mount point to it. Removing a message is just removing the meta file and the content from the message cache. Any link from the mdir mount dir will kept the file content of course. The user (or a program) may clean them away based on their link count.
Threads...