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!