Maybe the other folder types should simply be unavailable (i.e. greyed out) when accepting an encrypted folder?
Why does the entire connection between the two devices drop though? Is this expected?
More error messages, this time after trying to manually change the folder type in the advanced configuration. It does not seem to work though. Only by completely removing and re-adding the folder as “Receive Encrypted” I can get the two devices to connect.
2020-11-28 01:08:15 Connection to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiving index: illegal base32 data at input byte 1
2020-11-28 01:08:15 Exiting indexSender for rn5bb-vz5is to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256: service should not be restarted
I have mentioned this above but it probably got lost in my long posts, but I compiled from main (ab53687) today and have been testing using only that, so I should have all the encryption-related commits.
Hmm, but this seems to persist even after removing the folder from B… Only after removing the folder from A too and recreating it from scratch I seem to be able to get the two devices to connect again.
I don’t quite get anymore what exactly you are doing now and which error you see (there have been two: the encryption config one and the base32 one). Could you recap the current situation again please.
You aren’t suposed to change folder type from/to receive-encrypted. It’s possible that when before you already had scanned items while not being receive-encrypted, that after changing that those items were still around, causing this error.
That’s a noop change, just renameing id to device.
Some things may need to be greyed/disabled on untrusted side : ignores as this makes no sense (real file names being unknown), and some (if not all) styles of versioning (maybe simple trash can could perhaps be kept for restore purpose ?).
Keep zen devs, this is just cosmetic as long as Untrusted isn’t pushed in the wild, allow yourself to postpone.
Should Versioning be allowed in Receive Encrypted folders?
I would personally lean towards having it completely disabled (as it is the case with Ignore Patterns), because restoring files with encrypted names that we don’t know (or shouldn’t know) what they are doesn’t really make much sense.
It’s not obviously impossible for there to be a use case. The versioned files could still be decrypted by a tool. (I don’t off hand remember whether the built in decryptor looks in unexpected directories, but it could.)