Error Message

[Richard Long]

Svante,

I reverted back to Version 1 as you can see in Error message. One of the folders I worked and tested V2 with was the one having the error after reverting back. As I mentioned in a previous post (different thread) I did not like the fact that V2 did not allow KEEPING the date of original plain-txt creation. Because of that and other issues of temporary files lying around upon errors I am back on version 1.7.2893. I did do a REGED to put the KeepTimeStamp nonzero back in, but when I went to this folder which had all files at current date (11/20/2016) and tried to Decrypt them to get them all corrected (other files in other folders I had to revert worked), I got this error (see image). I can always get these back undamaged from backup files which should restore things to working again, I THINK. But, what does this error mean and can I correct anything to get AxCrypt working against the file (s)? Thanks.

 

 

[SvanteSpectator]

Hello,

The error message just means that the file was encrypted with version 2, not version 1. Version 1 is smart enough to realize this, but it cannot do more. The formats of the files produced are different, and while Version 2 supports Version 1 (i.e. it is backwards compatible), Version 1 cannot support version 2 and that’s what the message means.

As for the modification time stamp, version 2 does not support keeping the original date time stamp, since it was originally a bad idea and it breaks the promise that the time stamp provides. The encrypted file *is* a different file than the original, even if it contains the original. Thus, when you decrypt the file, the name *and* the original time stamp is restored. But the encrypted file is a different file, and should have a new time stamp. Most backup strategies will also fail if this is not done, since it may think the file was backed up, while in fact it was not (just the original plaintext).

To revert the files encrypted with Version 2, download the standalone version of AxCrypt 2, and decrypt them with that.

[Richard Long]

Thanks Svante, but I have don’t agree with your answer re keeping the original/modification date and here’s why: I have a file created on, say, 1/1/2000 and encrypt it. Both have the same date. I just double-click on it opening it on 2/1/2000 to just look at it and make no changes. When I am finished and I exit application without changes, the encrypted file remains 1/1/2000 and the file inside remains 1/1/2000. All is well and exactly like I want it. Now on 3/1/2000 I double-click it to open it and now change it and SAVE in the application. When I am finished, both the file inside and the encryption date are 3/1/2000. All is like I want it. After the 2/1/2000 open my incremental backup ignores it because the name and date did not change, i.e., both inside and encryption date and encrypted file name are the same as 1/1/2000. Just like I want it to ignore it when no changes were made. However, after the 3/1 change, the encrypted file date changes to match the inside file (now changed) date and my incremental backup notices the change and does its thing. Just like it is supposed to do. So, what are you trying to say? Are you telling me after the 2/1/2000 open my backup should recognize that as a changed file even though no changes were done? And even though the date remained 1/1/2000 it is really different in some way? I don’t understand your explanation.

Thanks for letting me know about standalone version. However, strangely, I made sure I decrypted all the files in question before going back to V1. Then I encrypted them within V1. After that I got the error. So, this explanation doesn’t the problem unless the actual inside file is altered too.  Am I correct? However, what might have occurred is that when I went back to V1 and encrypted, I did NOT have KEEP ORIGINAL DATE turned on. So the encrypted date differed from the original inside file date. Now I set KEEP on. then I tried to open one of the files and got the error. Regardless, I had backups of all encrypted files and restored them and back running.

I’m curious as to your KEEP original timestamp date explanation compared to my example. Are we looking at things the same or am I still missing something?

 

[SvanteSpectator]

Hi Richard,

I don’t really understand the issue about the time stamp. What you describe is exactly how AxCrypt 1 *and* 2 works by default.

The option that exists via registry in AxCrypt 1 is for the scenario that you encrypt a previously not encrypted file. Let’s say that the original plain text “file.txt” was modified on June 1, 2010. On November 23, 2016 you decide to encrypt it with AxCrypt, removing “file.txt” and creating “file-txt.axx”. In both AxCrypt 1 and 2, by default, the modification date of “file-txt.axx” will be November 23, 2016. With the option to “keep original file time stamp” of  version 1 set in the registry, “file-txt.axx” would have it’s time stamp set to June 1, 2010 – just like the original unencrypted file “file.txt”. This is behavior is no longer available in AxCrypt 2.

In both AxCrypt 1 and 2, when you decrypt “file-txt.axx” back to “file.txt”, the file will regain it’s unencrypted time stamp of  June 1, 2010.

The error message is shown because the file was encrypted with Version 2, but attempted to open with Version 1. Probably, you viewed with AxCrypt 2 after re-encrypting it – causing it once again to be auto-upgraded to version 2.

[Richard Long]

Svante,

I feel I’m not explaining things well enough for you to assess. Let me try again:

 

Date       Action                                               V2 Result       V1 with KeepTimerStamp=1

 

1/1/2016  Create file & encrypt only                 1/1/2016                1/1/2016

2/10/2016 View only by double-click in           2/10/2016              1/1/2016

File Explorer

3/19/2016  Open and modify file inside then    3/19/2016               3/19/2016

Encrypt

4/30/2016 View only by double-click in           4/30/2016              3/19/2016

File Explorer

4/30/2016 View only by double-click in           4/30/2016              3/19/2016

File Explorer

11/1/2016  View only by double-click in          11/12016               3/19/2016

File Explorer

 

If the encrypted file dates are as in the above chart, then I prefer V1 with KeepTime Stamp=1 set. If you think the chart is NOT descriptive of how V1 and V2 work, please hit me up again. As I said, my logic for V1 with KeepTimeStamp is that the actual file inside is NOT changed unless modifications are made, thus, my incremental backup and my searching for files last modified by date work like a charm. Let me repeat: If I wat to find the stock analysis I specifically worked on in March 2016, I want the ENCRYPTED file name to represent the date of the file inside, specifically 3/19/2016 as in chart above. If it is not kept the same as the file inside, my searches can not find the file when it is within the encrypted wrapper. Furthermore, If I want to write just incremental backups, meaning just files (within) that changed, I lose that function and always backup based on encrypted wrapper date regardless if it is the same as before or not if I simply viewed it at a later date.

 

My recommendation: Allow the user to decide as in V1 and provide options that are equivalent to V1 registry changes.

[SvanteSpectator]

Hi Richard,

The behavior for V2 you describe above is not how it works (except possibly) for the first open on 3/19/2016 *if* the file was originally encrypted with V1. If you really see this behavior, something else is going on.

As I mentioned, the only situation where the behavior should differ is your action on 1/1/2016 – the initial encryption.

Both V1 and V2, regardless of V1 registry options, should set the time stamp to the date and time of the last modification of the encrypted file.

Since an decrypt + open without any change does not require re-encrypting the file, it should be left entirely unmodified, including the last modified time stamp.

AxCrypt 2 does *not* update the last modified time stamp separately just because a file was accessed + decrypted. At least not it should not, and I cannot reproduce the behavior you describe, nor does the code to do this even exist in the software so it’s hard to see how it happens.

I should stress that there *is* one situation where AxCrypt 2 actually does update the encrypted file, even though you as a user only decrypt and open it without the intent to modify it. This is the situation described earlier, when you open a V1-encrypted file with V2. In this case, V2 will re-encrypt the file in the background in order to update it to V2.

Also, please ensure that you are checking the last *modified* time stamp, not the last *accessed* time stamp. The last *accessed* time stamp is disabled by default by Microsoft in more recent versions of Windows, since it is very wasteful and time consuming.

[Richard Long]

“I should stress that there *is* one situation where AxCrypt 2 actually does update the encrypted file, even though you as a user only decrypt and open it without the intent to modify it. This is the situation described earlier, when you open a V1-encrypted file with V2. In this case, V2 will re-encrypt the file in the background in order to update it to V2.”

Ahhhh. So, when I opened a V1 encrypted file (say, inside=encrypted =3/19/2016 because I set registry to KeepTimeStamp=1) on 11/20/2016, even though I just viewed it, V2 changed the encrypted timestamp to 11/20/2016. Is this what you are saying? If so, not nice for my file management. I really wanted it kept as 3/19/2016.

Anyway, if I understand now, from the time V2 is installed any NEW files I create, say on 11/21/2016 I created one, thus inside=encrypted=11/21/2016, will, according to your description, KEEP the encrypted date=11/21/2016 if later I just open it for review or simply decrypt it and not modify inside file. Right? In other words it behaves like KeepTimeStamp=1 on V1. Do I have it correct now?

So, if I install V2 and want to maintain V1 encrypted date, i.e., NOT have V2 change it the first time opened and NOT modified, is there a way to do this? If not, can’t we have an option to tell V2 to maintain the V1 encryption date even though it changes to V2 encrypted file?

[SvanteSpectator]

Hi,

We’re getting there ;-)

Let’s repeat it again – the V1 “keep time stamp option” *only* affects the situation where you take an unencrypted plain-text file and encrypt. It has no effect on the behavior when opening an already encrypted file.

Your file management will work as it should in the one situation described where V2 will actually update the encrypted file, even if you as a user only open it to view it. This is because the file *has* changed, and thus *should* be backed up again. Even if the file inside has not.

There are three situations that you should understand:

1. You encrypt a previously unencrypted file, say “file.txt” to “file-txt.axx”. This is the only situation where V1 and V2 behavior differs as a result of the V1 “keep file stamp” option.
2. You open an already V1-encrypted file with V2 the first time. This is when the encrypted file is actually updated, even if you do not actually modify and save the unecrypted file when you view it.
3. You open an already V1-encrypted file with V1, or you open an already V2-encrypted file with V2 and you do not modify it. In this case the encrypted file, and it’s time stamp, will remain unchanged because the encrypted file is not changed.

[Richard Long]

Svante,

Thank’s for summary. I understand it all now as you have explained, however, I do not agree that V1 timestamp should change for situation 22 above. It’s this situation after a V2 intall over a V1 that ran for years and years where hundreds or thousands of file were encrypted and have the timestamps=inside file timestamps and that I depend on them to be equal for searching reasons., in addition to backup schemes. I can understand that you think that for backup reasons that are dependent on timestamps to decide whether to backup or not that in order to get the V2 encrypted representation of the originally V1 encrypted file backed up, I need a new timestamp equal to the time it was opened, modified or not. But what is the harm of NOT backing up this old V1, now opened by V2? The inside file is still the same. yes? It sounds that somewhere in the encryption itself there is a designator that it has become V2 encryption and that is why you are indicating that it is still modified even if only opened for view. If this is the case, the issue becomes why is it important to flag this as newly encrypted V2 requiring a timestamp change from that of V1 case? If left alone, all would work again next time it is viewed, and on and on until the inside file is actually modified. Is it not the case now that in your implementation, the file BECOMES V2 always, thus, rendering it useless on another system where V1 is running? I know, the new design is to make it easier to mange across platforms. But, I have an old XP system where V1 is installed and now I must be careful not to put a newly encrypted V1 file on it replacing the file I already have there encrypted actually by V1. Maybe an alternate design where V2 changes the SUFFIX from .axx to something else would have made it clearer and easier than changin timestamps. Just my thoughts. I do now understand how V2 works (I think) and know for new users it will be as excellent as V1.

Just to clarify. If I have NO V1 files, V2 encryption and the setting of timestamps will ALWAYS work like V1 did with KeeptimeStamp=1. Correct?

[SvanteSpectator]

Hi Richard,

I’m glad we’re now almost clear on how this works. But not quite. You write: “If I have NO V1 files, V2 encryption and the setting of timestamps will ALWAYS work like V1 did with KeeptimeStamp=1. Correct?”.

No. Incorrect. I’ll say it again:

– The only time the Keep Time Stamp setting has any effect is when you are encrypting a given file for the first time. So, when working with already encrypted files, V1 and V2 behave identically – regardless of the setting of Keep Time Stamp setting in V1.

Often, I keep the door open for modifying the behavior of AxCrypt according to user feedback. But this is probably one area where I’m afraid I won’t budge. Fooling around with the time stamps was always a bad idea – it just took some time for me to realize it, but that was more than 10, closer to 15 years ago.

The time stamps mean “when was this file last updated”. And that’s what it should say. Not “when was something inside last updated”. Everytime we try to “lie” to the system, we’ll get punished for it sooner or later. Therefore AxCrypt won’t lie anymore with the timestamps. If a file is modifed, the timestamp is updated.

When a file is decrypted, that is equivalent to a restore operation, and then it makes sense to restore the time stamp as well – which is what is done.

[Richard Long]

Svante,

First I agree with you now. I have included test scenarios below for clarification only with the bottom line to change my file management scheme: Use timestamps as in V2 for backups, but include original date in the file name for my historical searches should I need a never-modified file that I occasionally open to look at only. Thanks for helping me understand both your implementation and limits/perils of using timestamps as I was doing.

 

Environment: AxCrypt V1:

 

Action                                                 Inside timestamp                Encrypted wrapper timestamp

1. Create a file B.Doc                         11/25/2016 1:39 PM

2. Encrypt B.doc to B-doc.axx           11/25/2016 1:39 PM               11/25/2016 1:39 PM

3. Decrypt B-doc.axx to B.doc          11/25/2016 1:39 PM

4. Encrypt B.doc to B-doc.axx           11/25/2016 1:39 PM               11/25/2016 1:39 PM

5. Decrypt B-doc.axx to B.doc          11/25/2016 1:39 PM

6. OPEN (double-click) ONLY          Unknown until step 7             11/25/2016 1:39 PM

7. Decrypt B-doc.axx to B.doc          11/25/2016 1:39 PM

8. Encrypt B.doc to B-doc.axx           11/25/2016 1:39 PM               11/25/2016 1:39 PM

9 OPEN and MODIFY                      Unknown until step 10           11/25/2016 1:39 PM

10 . Decrypt B-doc.axx to B.doc       11/25/2016 1:50 PM               11/25/2016 1:39 PM

 

I now see the errors using V1 like this. If KeepTimeStamp=1 set, the encrypted wrapper will NEVER change from the originally created and first-time encrypted timestamp, but later if the inside file was changed, it’s timestamp does change to time modified, but, once again as we see above, the outside encryption wrapper remains the timestamp of first-time encrypted. Not good.

 

Another scenario, same environment:

 

1. Existing file C-pdf-axx                                                                   11/20/2016

2. OPEN C-pdf.axx                                                                            11/20/2016

3. Decrypt C-pdf.axx to C.pdf           10/05/2016 9:09 PM

4. Encrypt C.pdf to C-pdf.axx                       10/05/2016 9:09 PM               10/05/2016 9:09 PM

 

Note: This specific file was opened with V2 on 11/20. When I went back to V1 I had to restore the encrypted V1 file from file backup. The restored encrypted file took on the RESTORED date. The inside was will original date. When I reencrypted it with V1 and KEEP Timestamp=1, the encrypted file took on the original timestamp again. So if your description is correct, V1 recognized this as a FIRST encryption even though it was already encrypted and decrypted before reencrypting it again. Fine. It’s close to your decription.

 

Let me explain that the second scenario represents files I NEVER modify, like bank statements, broker statements, important final letters, etc. Thus, I preferred the KeepTimeStamp=1. An alternative scheme I could have used is to always include at least YYYYMM in the file name. This would have made my file management independent of actual timestamps, but wouldn’t be the most friendly for incremental backups.

 

Scenario 1 showed me the problem with KeepTimeStamp=1 for files I might modify in that the encrypted date should have taken on the inside modified date for proper backup management. Scenario 2 showed me that it was desired for files never modified. I wish there would have been a never-modified-bucket I could have dropped scenario 2 files into using KeeptimeStamp=1, and a different bucket for files I might modify. I need to change my file management scheme regardless if on V1 or V2. I guess that’s the bottom line and I value your explanations and time. Give me a few weeks to change to something workable with V2, and V1 as a matter of fact. I learned my lesson re timestamps!

[Author]

Posts