Hi.
As far as I remember the date issue was that the date of encryption was set and was overwriting the original date. (Keep modification date and other dates of original file · Issue #220 · cryptomator/cryptomator · GitHub )
This was fixed with 1.4 (and had a regression which was fixed with 1.4.11)
[Bug] Timestamp problem in Cryptomator v1.4.7 (Windows)
So version 1.4.6 that you are using should not be affected. However, the actual Version is 1.4.13 and I recommend an update.
Your issue #2 is hard for me to reproduce. Can you please post a step by step guide what you do, how the system acts, and what you expect how it should act.
Maybe these known issue is also a cause:
Microsoft Office applications (Word, Excel, and PowerPoint) have a bug that they can’t properly load a file within a WebDAV share when its name has a special character (e.g., an umlaut like “ö”). The files are successfully saved/encrypted so there is no “data loss”. But if you re-open the file, the Office application will load an old version (probably from its internal cache). If you close the file and rename it, the Office application will correctly load the file.
The workaround is not to use …
Currently Cryptomator is still using WebDAV technology to provide the virtual hard drive you see in Windows Explorer. Technically WebDAV is a web protocol and MS Office programs think they need to be very smart handle communication via this web protocol using the Upload Center instead of letting the operating system do it.
Hence saving an Office document looks as if it would be uploaded. If you take a closer look at the “Speicherort”, you will see, that your .xlsx file is uploaded to http://cry…
If yes, you can try and switch the volume type to dockany to solve this.