The file remains open, although it has been closed in the application

[Chema]

I have detected that there is a problem with how AxCrypt detects that the file has been released so that it can be re-encrypted and deleted from the temporary directory.

The case is as follows:

– I have Word open with a document I’m writing.

– Now I open an encrypted file with a .axx extension with a double click that contains a Word .docx file. The file opens in a new Word window perfectly.

– Now I close the encrypted file that I just opened in the new window and only the other Word document that I previously had open in another window remains.

– But it happens that AxCrypt does not detect that the file has been closed in Word, it continues to detect it as if it were still open and does not proceed to encrypt the temporary file again and then delete it.

– It only detects that the file has been released and then proceeds to encrypt it and delete the temporary file when I close the other Word window that I had open at the beginning, that is, when there is no longer any instance of the Word application open in memory.

This is a serious problem, AxCrypt is not able to properly detect that the file has been released by Word and that it can and should proceed to re-encrypt the temporary file and delete it. This way, you could leave the other Word window open all day trusting that the other file has been encrypted correctly, when in reality it has done nothing.

It seems that AxCrypt is only guided by the name of the executable that opens the file to detect when the file is released, that is, in this case it detects that the file is opened with Winword.exe and until it detects that there is no longer any running instance of that application in memory, it does not encrypt the file again.

This, from my point of view, is a serious failure in how it is detected whether the file has been released or not, since, as in this case, the file is opened in the same instance of Winword.exe that was already open with the other window, but then the second Word window closes and the file is released, and AxCrypt doesn’t even notice this because all it does is wait for there to no longer be a Windword.exe running in memory, which it’s a disaster, as you can see.

I think you have to change the way you check this, you have to find a way to know if the file has been released correctly or not. You know that many applications open the file in exclusive mode, so in this case you can know if the file has been released or not by launching requests every few seconds that involve some writing operation on the file (for example, trying to change some attribute of the file, such as making it hidden or read-only or any other attribute or metadata of the file), in such a way that if the file is locked, an error will be returned to you and this way you can know that it has not yet been released.

Now, for applications that do not block the files, I understand that in this situation it is more difficult since the case that I explained above would not work here and I know that it is much more complicated to be able to know if the file is still open in an application or not, since the file would only be open in the application memory.

You have to think about this carefully, I know it is not easy, but you have to find a way to fix this, since as I say right now the detection of the file release is a disaster and a serious security problem leaving the temporary file decrypted in disk much longer than necessary.
<div id=”jpdictionary”>
<div class=”o-search-mobile” style=”top: 0px; left: 0px; display: none;”></div>
<div class=”o-popup-tag o-bg-white o-border o-rounded o-shadow” style=”width: 400px; top: 0px; left: 0px; display: none;”>
<div><button class=”btn-sm o-btn-close o-position-absolute o-top-0 o-end-0 o-mt-1 o-me-1″ type=”button” aria-label=”Close”></button>
<ul class=”o-nav o-nav-tabs o-pop-nav” role=”tablist”>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link active” data-bs-toggle=”tab” aria-selected=”true”>Word</div>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link” data-bs-toggle=”tab” aria-selected=”false”>Kanji</div>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link” data-bs-toggle=”tab” aria-selected=”false”>Translate</div>

<div class=”o-selected-result o-pt-1″>
<div>Searching for …</div>
<div class=”o-fs-6 o-mt-2″ style=”line-height: 1.7;”>
<div class=”o-float-start”>Hide this time</div>
<div class=”o-float-end o-me-1″>JP Dictionary</div>
</div>
</div>
</div>
</div>
</div>
<div id=”jpdictionaryOff”></div>

[Chema]

Sorry, I don’t know what happened when I wrote the message in the final part, I’m pasting it here again:

I have detected that there is a problem with how AxCrypt detects that the file has been released so that it can be re-encrypted and deleted from the temporary directory.

The case is as follows:

– I have Word open with a document I’m writing.

– Now I open an encrypted file with a .axx extension with a double click that contains a Word .docx file. The file opens in a new Word window perfectly.

– Now I close the encrypted file that I just opened in the new window and only the other Word document that I previously had open in another window remains.

– But it happens that AxCrypt does not detect that the file has been closed in Word, it continues to detect it as if it were still open and does not proceed to encrypt the temporary file again and then delete it.

– It only detects that the file has been released and then proceeds to encrypt it and delete the temporary file when I close the other Word window that I had open at the beginning, that is, when there is no longer any instance of the Word application open in memory.

This is a serious problem, AxCrypt is not able to properly detect that the file has been released by Word and that it can and should proceed to re-encrypt the temporary file and delete it. This way, you could leave the other Word window open all day trusting that the other file has been encrypted correctly, when in reality it has done nothing.

It seems that AxCrypt is only guided by the name of the executable that opens the file to detect when the file is released, that is, in this case it detects that the file is opened with Winword.exe and until it detects that there is no longer any running instance of that application in memory, it does not encrypt the file again.

This, from my point of view, is a serious failure in how it is detected whether the file has been released or not, since, as in this case, the file is opened in the same instance of Winword.exe that was already open with the other window, but then the second Word window closes and the file is released, and AxCrypt doesn’t even notice this because all it does is wait for there to no longer be a Windword.exe running in memory, which it’s a disaster, as you can see.

I think you have to change the way you check this, you have to find a way to know if the file has been released correctly or not. You know that many applications open the file in exclusive mode, so in this case you can know if the file has been released or not by launching requests every few seconds that involve some writing operation on the file (for example, trying to change some attribute of the file, such as making it hidden or read-only or any other attribute or metadata of the file), in such a way that if the file is locked, an error will be returned to you and this way you can know that it has not yet been released.

Now, for applications that do not block the files, I understand that in this situation it is more difficult since the case that I explained above would not work here and I know that it is much more complicated to be able to know if the file is still open in an application or not, since the file would only be open in the application memory.

You have to think about this carefully, I know it is not easy, but you have to find a way to fix this, since as I say right now the detection of the file release is a disaster and a serious security problem leaving the temporary file decrypted in disk much longer than necessary.
<div id=”jpdictionary”>
<div class=”o-search-mobile” style=”top: 0px; left: 0px; display: none;”></div>
<div class=”o-popup-tag o-bg-white o-border o-rounded o-shadow” style=”width: 400px; top: 0px; left: 0px; display: none;”>
<div><button class=”btn-sm o-btn-close o-position-absolute o-top-0 o-end-0 o-mt-1 o-me-1″ type=”button” aria-label=”Close”></button>
<ul class=”o-nav o-nav-tabs o-pop-nav” role=”tablist”>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link active” data-bs-toggle=”tab” aria-selected=”true”>Word</div>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link” data-bs-toggle=”tab” aria-selected=”false”>Kanji</div>
<li class=”o-nav-item” role=”presentation”>
<div class=”o-nav-link” data-bs-toggle=”tab” aria-selected=”false”>Translate</div>

<div class=”o-selected-result o-pt-1″>
<div>Searching for …</div>
<div class=”o-fs-6 o-mt-2″ style=”line-height: 1.7;”>
<div class=”o-float-start”>Hide this time</div>
<div class=”o-float-end o-me-1″>JP Dictionary</div>
</div>
</div>
</div>
</div>
</div>
<div id=”jpdictionaryOff”></div>

[Chema]

Sorry, I don’t know what happened when I wrote the message in the final part, I’m pasting it here again:

I have detected that there is a problem with how AxCrypt detects that the file has been released so that it can be re-encrypted and deleted from the temporary directory.

The case is as follows:

– I have Word open with a document I’m writing.

– Now I open an encrypted file with a .axx extension with a double click that contains a Word .docx file. The file opens in a new Word window perfectly.

– Now I close the encrypted file that I just opened in the new window and only the other Word document that I previously had open in another window remains.

– But it happens that AxCrypt does not detect that the file has been closed in Word, it continues to detect it as if it were still open and does not proceed to encrypt the temporary file again and then delete it.

– It only detects that the file has been released and then proceeds to encrypt it and delete the temporary file when I close the other Word window that I had open at the beginning, that is, when there is no longer any instance of the Word application open in memory.

This is a serious problem, AxCrypt is not able to properly detect that the file has been released by Word and that it can and should proceed to re-encrypt the temporary file and delete it. This way, you could leave the other Word window open all day trusting that the other file has been encrypted correctly, when in reality it has done nothing.

It seems that AxCrypt is only guided by the name of the executable that opens the file to detect when the file is released, that is, in this case it detects that the file is opened with Winword.exe and until it detects that there is no longer any running instance of that application in memory, it does not encrypt the file again.

This, from my point of view, is a serious failure in how it is detected whether the file has been released or not, since, as in this case, the file is opened in the same instance of Winword.exe that was already open with the other window, but then the second Word window closes and the file is released, and AxCrypt doesn’t even notice this because all it does is wait for there to no longer be a Windword.exe running in memory, which it’s a disaster, as you can see.

I think you have to change the way you check this, you have to find a way to know if the file has been released correctly or not. You know that many applications open the file in exclusive mode, so in this case you can know if the file has been released or not by launching requests every few seconds that involve some writing operation on the file (for example, trying to change some attribute of the file, such as making it hidden or read-only or any other attribute or metadata of the file), in such a way that if the file is locked, an error will be returned to you and this way you can know that it has not yet been released.

Now, for applications that do not block the files, I understand that in this situation it is more difficult since the case that I explained above would not work here and I know that it is much more complicated to be able to know if the file is still open in an application or not, since the file would only be open in the application memory.

[Author]

Posts