-
-
Notifications
You must be signed in to change notification settings - Fork 983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Office 365 files stored in a vault won't open when I'm offline #527
Comments
Additional info: I disabled the Office Synchronisation in Onedrive (Office Upload Centre): OneDrive Properties -> Office -> Office-Dateien, die ich öffne, mit Office 2016 synchronisieren. |
Hey guys, |
I guess the problem here is, that the Office Upload Centre does some "magic" stuff when opening office files from Cryptomator and because some errors and bugs exist in the Upload Centre itself office tells you the weird stuff about that the path could not be opened or would be an offline copy. You told us, that it is possible to copy the file out of Cryptomator and open it from your desktop. This prooves that access to the file is possible (because if a file could not be read it could not be copied to another location). Thus it is not really a problem of Cryptomator providing the files the wrong way but more a problem of Office trying to do the wrong stuff to read the file. For now our possibilites to fix this from within Cryptomator are limited. We can not change the way office tries to access the files. The workaround suggested by you - copying the file to the desktop, edit it there, and copying it back to the vault is currently the way to go. The only way to really fix this is to wait for Microsoft to improve how Office handles files from so called WebDAV shares (this is how Cryptomator provides the virtual drive). Nevertheless we are working on an improvement of our filesystem interface (especially to increase performance) and will provide a dokany implementation ( #207, no date scheduled yet). This should as a side effect also solve this issue. |
I see your point and although it does look like Office is at fault, it doesn't change the fact that working straight out of a vault doesn't work with Cryptomator and the workaround is a bit of a hassle... |
All right, maybe this helps you: After some testing, I could effectively disable / kill the dreadful Upload Center using this hint and my Comodo Firewall: https://answers.microsoft.com/en-us/office/forum/office_2016-officeapps/office-2016-upload-center-how-do-i-get-rid-of-it/e471b430-d940-4b6c-88ec-af0336cd3e93?auth=1 Now it does not start anymore when I try to open or save an Office Document. However, the error still pops up. |
I understand what you did and if it worked this way disabling Upload Center would be the way to go. Obviously Office does not actually not need the Upload Center to behave broken. As before, the fact that access to the files is possible when copying it out of the vault means that access to the file in Cryptomator is possible. Office must just not be doing it right. To make this clear: We are not happy with the situation and although we believe that this problem is actually caused by Office we of course want it to be solved. Currently we do not have any options to solve it because we do not understand what acutally goes wrong. If we have a way to fix this in a reasonable way and with reasonable effort we will do so. I tried to reproduce the problem today and analyze it further but did not succeed. Maybe we will succeed if we have more information about the exact steps. The following could help us:
Just a question before I dig further into it: In your report (but its 6 weeks old now) you mentioned you are using 1.3.0-RC8. Did you update Cryptomator to the latest version yet and do you still have problems? |
Thank you for your trouble. To answer your questions:
Interestingly enough, the documents that I could not open and I then copied to the Desktop and - after working with them - back into my vault, DO open. MS word says: "Dies ist eine Offlinekopie des Serverdokuments, die am 12.09.2017 um 12:20 Uhr aktuell war." Word files I have not copied and used to replace the original file in the vault still give out the error. |
@An-error-occurred |
Hey there, |
Hello, Hope this helps... |
@rmti haha great workaround :D Sometimes Windows is simply insane. Thanks for sharing! |
Here's more info that might prove helpful: If there's no WiFi-connection: Problem as described in great detail. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
bump |
Good news, everyone! We've released version 1.4.0-beta2, which introduces Dokany support. You now have the choice between Dokany and WebDAV based virtual hard drives. Please retest this issue with Dokany enabled. |
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. |
This is a bug report.
I'm using Windows in version: Win10 Pro 1703; Build 15063.413
I'm running Cryptomator in version: 1.3.0-RC8
Description
OFFICE FILES DO NOT OPEN WHEN I'M NOT ONLINE
Pictures will load and if I copy the office file (Word or Excel) to another folder outside the vault, I can read and edit the files. The error reads: "[Pfad] konnte leider nicht geöffnet werden". It both concerns my Surface and my desktop PC (identical Win version and Office).
This is a major issue, since I cannot be online all the time with my portable device.
Workaround
This issue is not directly caused by Cryptomator but is a sideeffect of Office and the Office Upload Center not working correctly.
One workaround for this issue is to copy the files in question to another directory outside of the vault (e.g. the Desktop), work with the files from there and copy back to the vault afterwards.
Another workaround is to use the subst command on the virtual drive. So if the encrypted drive is drive F: you may run
subst G: F:
. When using drive G: afterwards you will not recieve this warnings.The text was updated successfully, but these errors were encountered: