[SvanteSpectator]

Thanks Gulliver! Great answer.

[SvanteSpectator]

Thank you AK-Neuss for the additional information. I think we need to know more to understand this.

Can you please follow the instructions here https://forum.axcrypt.net/blog/send-complete-error-report/ and send the information to support@axcrypt.net ?

[SvanteSpectator]

Thanks Robin!

[SvanteSpectator]

Thanks Aiden!

[SvanteSpectator]

Hello Rohit,

Thanks for the suggestion!

[SvanteSpectator]

Hello Ollie,

thank you for the information. If you’ve read this thread, you’ll also see my repeated pleas:

– Send me a copy of a file that seems to be signed at the wrong date, and/or with the wrong hash. Please!

We *really* need to get hold of such a file to inspect it, if it’s really out there.

[SvanteSpectator]

Hello AK-Neuss,

We’ve not heard of this particular situation before. Just how do you close the file in Excel? How does the recent files window look before and after close the file? If you can send a screen shot it would be great!

[SvanteSpectator]

Hello questionfile,

AxCrypt 2 uses %localappdata%\axcrypt for working files, settings and temporaries (and subdirectories thereunder).

From what you write, it seems you’re running AxCrypt 1? The tmp file you are referring it likely just working memory for AxCrypt if it’s AxCrypt 1 and does not contain any file data.

[SvanteSpectator]

Hello questionfile,

Here’s how AxCrypt works:

1. When you open a file, it is decrypted to a temporary location, and then Excel is launched to open that temporary file.

2. When AxCrypt (which stays resident) detects that Excel is exited, it takes the temporary file and re-encrypts it back to the original location and then wipes the temporary decrypted file.

If AxCrypt crashes or is killed between 1. and 2. it can’t perform step 2, and while you’re saving the Excel file to the temporary location the encrypted original file won’t get updated.

However, the temporary file is still there, so if you notice this you can manually find it. With AxCrypt 2 it also detects that there’s an ‘orphan’ decrypted file, and you can click the clean ‘broom’ icon for example to get the decrypted file re-encrypted and update the encrypted file.

[SvanteSpectator]

Hello Dan,

I can assure you that upgrades / downgrades between versions is *not* the issue here. The file was damaged (or was never an AxCrypt file) before the upgrade scenario.

Under certain circumstances, this can happen with version 1.7.x – namely if the file is on a USB stick, and you remove the USB stick too quickly without using the Windows function to “remove safely”.

[SvanteSpectator]

Hello Patrick,

AxCrypt has always had problems with OpenOffice / LibreOffice. If you ensure that you only have one document open at a time, and close OO/LO completely, it works better.

With version 2, instead you decided when it’s time to re-encrypt, by clicking the ‘broom’ clean icon when you’re done with the document.

[SvanteSpectator]

Hello Chris,

We might not make Q1 2017 quite, but we are working full time on it now!

[SvanteSpectator]

Hello Benoit,

So many things we want to do… Yes, a command line version is also on the to-do list!

[SvanteSpectator]

Hi Tomzzz,

There’s some confusion here… There’s no difference in behavior between 2.1.1481 and 2.1.1489. Both versions are published as installer packages, and portable stand-alone softwares. Both use the “sign in” metaphor to retain and cache the password used for encryption and decryption. Both will stay in memory until exited. I’m guessing you have the 1481 standalone, and the 1489 installer. The uninstaller uninstalls cleanly as far as we know.

The older, non-maintained, version 1.7.x also stays in memory, and is actually harder to “exit”.

A common misconception is that it’s a problem having programs loaded in memory. Generally speaking, it’s not. Windows will also unload stuff that’s not needed. AxCrypt typically uses about 30M of ‘private’ memory, i.e. non-shared memory that contains real information that cannot be recovered from the image or the system and thus must either remain in memory or be written and saved to the page file if it must be ejected from memory.

In an 8GB system, that’s not even half of a percent of physical memory.

AxCrypt needs to stay in memory to work at all, at least during the period from when a file is opened to when it’s closed. If the ‘Secured Folders’ feature is used, which facilitates to keep folders encrypted, it also needs to stay in memory in order to monitor what’s happening.

Finally, memory is there to be used! There’s absolutely no reason to have a lot of free memory. Y0ur system won’t be faster because you have free memory. Most likely it’ll be slower. A ‘perfect’ memory management system will under load keep your memory utilization to 100%.

On the contrary, in Windows (and Linux) starting a new process – now that’s a performance killer! It’s a very ‘heavy’ operation, and should be avoided if possible. In essence, to a limit, staying in memory makes your system faster, not slower.

[SvanteSpectator]

Hi Glazooh,

Thanks for the feedback. Problem is – I can’t reproduce the behavior. Using Windows 10 and Notepad it appears to work as expected, both with one or several encrypted text files open.

You seem to know your way around Windows. Check with Task Manager if all instance of Notepad.exe have been closed, and you still have the broom. You can also try to find what’s keeping the file open (if that’s what happening) using Resource Monitor. Open Task Manager, then the Performance Tab. There there’s a link to open Resource Monitor. Select the CPU tab. Then there’s a section call “Associated Handles”. Search for your file there. Normally, Notepad will *not* actually keep a text file open.

[Author]

Posts