August 30, 2017 at 22:04 #7709
I am running the latest version of AxyCrypt Premium on two Macs (v. 2.2.381) and one windows server (v. 2.1.1536), which are all connected to the same network. I am using the same account login information on all machines. I use both of the Macs and the server to access encrypted files which are saved in a shared folder on the server. When I open an encrypted file on the server and make / save changes, these changes are not visible when I open the same file on either Mac (although I can see, from both Macs, that the document has been modified). The same holds true when I make changes to an encrypted file using one of the Macs, then attempt to open the same file on the other Mac. The changes are only visible if the document is first decrypted. Conversely, when changes are made to an encrypted file using either of the Macs, they are immediately visible when the file is opened on the server.
I am encountering this issue with both Excel and Word files (I have not tested additional file types).August 31, 2017 at 00:14 #7710
I’ve not observed this behaviour myself and I would have been tempted to say it was a problem with your network share but for the fact you say that you can see “that the document has been modified”, presumably by looking at the last modified date and time.
I’m not convinced the problem is with AxCrypt because you say the changes aren’t reflected in the encrypted file unless you decrypt the file first; I’m assuming at the minute you’re double-clicking to open the file which is the recommended method.
Could this be something to do with the Microsoft version control in Word and Excel? That would account for the updated last modified time but only on the decrypted file (.docx or .xlsx); it shouldn’t affect a .axx file.
I suspect the most likely culprit is some type of versioning on your network share where it caches a copy of the file and when you go to open it (even though it shows a new modified time) the network share hands over the previous version until the current version. If you were to restart the network share by disconnecting and reconnecting on the endpoints, after modifying the file and saving it, this would help confirm if this is the cause. If this is to blame then you can normally disable local caching.
As you’re a premium customer you’ll get priority technical support from AxCrypt if you copy and paste your question in an email to them: email@example.com. Most people, myself included, are fellow customers in this forum and this may require you submit a debug log in order to get it resolved.
I’ve used AxCrypt on a Windows network share (Windows to Windows) and this doesn’t reproduce.August 31, 2017 at 06:44 #7711
Simultaneous access of a shared file on a network share is always a little tricky and not something Windows really supports.
With AxCrypt it gets even more so.
When you open an AxCrypt-encrypted file (double-click), what happens is the following:
1) The file is decrypted to a temporary location on your local hard drive.
2) Your local copy of AxCrypt marks the file as “open for editing”, and tries to keep track of when it’s time to re-encrypt it. It lights the red “Broom” (clean up) icon in order to indicate this. AxCrypt cannot successfully keep track of all situations and determine when you’re done with the file, so sometimes you may have to do this manually by clicking the broom icon.
3) AxCrypt launches whatever application Windows thinks is best for the decrypted file (Microsoft Office or Excel in your case).
So, this is the situation when someone starts editing the file, on the mac or the windows server. After making some changes, you click ‘Save’. This saves it to the temporary location on your hard drive. Since you still have Word / Excel open, AxCrypt will typically not re-encrypt the update to the shared encrypted file (this behavior depends on the individual application and the situation at startup, but for Word / Excel this is what happens).
Thus, while you’re happily editing and saving changes, these are only saved to the temporary decrypted copy. Until you fully close Word / Excel, at which point they file will be automatically re-encrypted to the shared location, and changes made visible to others – *if* they open the file after the update.
Note that AxCrypt does not stop more than one person from editing the file at the same time (we’re working on at least blocking more than one person from making updates but we don’t have that just yet).
If the situation arises that several people are editing the same file at the same time, “last one to save and exit wins”.
The part in your description I can’t explain is: “I can see, from both Macs, that the document has been modified“, unless you by this mean that while the same file is open on the Mac, and you look at the share, you see the last modification date has been updated. If the file is not open on the Mac, and has been cleaned (no red broom icon), then if you open the (modified) file, the changes should really be seen on the Mac as well.August 31, 2017 at 20:36 #7714
I believe I’ve isolated the issue to the Macs. The temporary local decrypted files are not being deleted after I’m done editing, even after fully closing Word / Excel, and even after clicking the red broom icon. This is happening on both of the Macs. Thus, on each Mac there is a decrypted copy of every AxCrypt-encrypted file I’ve ever opened on the Mac (which obviously isn’t ideal). This is the case not only for AxCrypt-encrypted files saved in the shared folder on the server, but also for AxCrypt-encrypted files saved locally on the Macs.
Although the temporary decrypted files are not being deleted, is appears that AxCrypt is properly re-encrypting any updates to the shared encrypted files, as saved updates are immediately visible when a file is accessed from the Windows server.
The Windows version of AxCrypt is not experiencing this issue. I’ve confirmed that all of the temporary local decrypted files are being properly deleted when I’m done editing.September 1, 2017 at 16:04 #7718
Thank you for the report, we’ll be looking into this asap. You can follow progress here: https://bitbucket.org/axcryptab/axcrypt-xwt/issues/168/temporaries-are-not-cleaned .