A remote of type crypt may be configured according to several options related to file name encryption. Multiple encryption techniques are available, and encryption of names may apply to regular files only, to both files and directories, or to neither.
In some cases, a user may wish to keep the top level directories in plain text, but to encrypt lower level names, of directories and files.
For example, consider a local tree, of content in plain text, structured as follows:
public1/
public2/
private1/
private2/
A user may wish to synchronize the tree with a remote target, but encrypt only private1 and private2, keeping the top level names as plain text.
If the crypt remote type supported an option for preserving only the top-level names in plain text, then a user could configure a remote target as such, and separately synchronize each top-level directory, either directly or through the crypt wrapper, according to privacy demands.
Would other users benefit from such a feature? Would it be considered for development?
Yes, separate remotes may be a viable workaround in cases of a small number of static directories, but the solution is not dynamic or scalable.
While the request may present initially as narrow or niche, it actually represents a common use case, as would be the normal one in file-synchronization systems that support folder-level client-side encryption. In this context, an encrypted directory has a plain-text name and sits in the same listing as directories that are not necessarily encrypted.
If it seems too rigid to fix the boundary between encrypted and plain-text folder names to just below the top level, another option may be available, depending on the current design.
Consider the following command:
rclone sync a/b/c cryptremote:x/y/z
The software could keep the names x, y, and z as plain text, but follow the existing rules for managing content in a/b/c. Of course, current behavior should be preserved by default.
Imagine a complicated file tree. Some directions within it have sensitive content, which should not be exposed on the server. Other folders should be stored in plain text. The proposed functionality allows embedding the encrypted content seamlessly into the plain-text tree.
Similar behavior is available from current remote-storage solutions. An overall tree may be stored as plain text, with specific directories selected for encryption. The names of these directories themselves are not encrypted (because they are the children of plain-text parents).
so rclone would have to keep a database of the crypt state every top level folder?
as folders are created and deleted, that database would have to be updated?
I am most familiar with Nextcloud, which is currently developing a client-side encryption extension in which specific directories marked for encryption are automatically handled as such by the client. I imagine that this design follows from precedent in other products, though I have not investigated.
Naturally, this model is not quite suitable for rclone, but a similar effect may be achieved by slightly extending the existing feature set.
The idea you might consider is that the user may synchronize various directories within a pre-existing skeleton (or one generated on-the-fly) using a sequence of commands, each targeting a location in a remote.
For example, consider the following command sequence.
The two private directories (and any other later added) are handled through the single encrypted remote, whereas the public directories are handled without encryption.
The effect is the same as though the four directories were handled by Nextcloud, with two marked as encrypted. At the top level sit four directories with unencrypted names, but the contents of two are stored securely.
to enable two sets of overlapping top-level folders, some crypted and some not crypted; rclone will have to have database.
when adding new top-level folders, a way to tell rclone to crypt or not to crypt and for rclone to update its database.
how will rclone know which top level folders are crypted and which top level folders are not crypted?
for most every operation, rclone will have to check the crypt status of the top level folder.
Same effect that happens now. I don't see why the proposal would affect this case, or why it should affect this case, or why any danger results from no such effect.
I would propose an option to change the behavior of specific encrypted remotes. The plain-text backend would not be affected.
While I accept that some additional value may be gained by tracking certain directories as encrypted versus plain, I believe that the basic feature, without such additional support, is adequate for a wide range of use cases, without significant danger.