Improper queue of events

[Giovanni Pugliese]

Hi,

I downloaded the free version of AxCrypt a few days ago solely for trial. I encrypted a directory to see how it worked, and after a few minutes of trying out the version, I selected to un-encrypt the directory. When I did this, I noticed not all files were un-encrypted, a few stayed encrypted. That seem odd, so I manually un-crypted those file through the right click context menu. I looked at the folder, everything looked normal, so I left.  A few days passed, and yesterday when I went to look at the folder, there were encrypted files. This was alarming, because I don’t fully remember the password (I was trying it out and didn’t think I would need it so I just didn’t focus on it )and long story short, I’m certain those files are lost.

What I believe happened: All of the files that are now encrypted are very large files, probably hundreds of megs to a couple of gigs depending on the file. Since I’m 100% certain that when I left the folder, everything looked normal, is that your application probably does the encrypting process on a seperate thread of operation. You right click on a folder, and it begins to iterate through the files and encrypt them and obviously the larger files may take many minutes, maybe even hour to complete depending on file size. However, if I right click on a folder and select to ‘decrypt’, it doesn’t look like that event probably cancels the initial event, or is at the very least queued up to occur once the encrypt completes. I’m a software developer; I see this as a bug. If there is an operation occuring in the background, and a user selects to undo the operation one of two things should happen; Either the event is respected, queued to occur of if possible, causes the previous action to stop, or a message should be displayed that certain files are in progress and may not decrypt ( please wait until all files are encrypted and try this operation again ). I’m pretty much screwed now because the software encrypted files probably long after I had turned the monitor off.

Anyways, I’m reporting this to prevent some other poor soul from doing having the same problem.

[SvanteSpectator]

Hello Giovanni,

Thank you for your feedback. Your scenario description sounds fairly likely to be what happened.

I am sorry if you have lost data, but I must object a little at focusing on the operations performed here. We warn you many times, and force you through a procedure where you must enter the password at least three times – all in order to ensure that you are really aware that you really need to know the password.

It is also essential to understand that one should never experiment on live data without backup. Here we should perhaps be even more clear, and have yet-another-popup pointing this out. Always have backups! Regardless of encryption or not.

Now to the heart of the matter. What should AxCrypt do when a background operation is in progress, and another one is started? I can agree in principle that a later operation that negates a pending operation can be optimized away. However, technically it gets complicated. We don’t expand the list of all files until necessary, and it just get’s pretty hard.

We could simply forbid two batch operations going on at the same time, but even that gets complicated. The whole idea of doing things in the background for long running operations is that the user can continue to do other work.

I just don’t know. Also, it’s the first instance of this scenario that I’ve heard of since we launched AxCrypt 2, so it’s not a common thing.

I think doing a quick-fix here is going to do more harm than good. We do have other registered issues about making the progress more clear, now it’s a little unobtrusive. That could help in this kind of scenario.

[Giovanni Pugliese]

Hi Svante,

Thank you for your response. And let me clearly state; You are correct in that I should not have tested this with an actual folder with data that I would have liked to have kept. And so perhaps I can echo your warnings to any users out there; If you are downloading and evaluating the software, do it on data that is either backed up or something you can afford to lose. And make sure you keep track of the password; There was really no excuse for me to pay a little more attention when I was testing it.

With respect to what to do, I understand your point with respect to wanting to let users do background operations to get on with their work. But ultimately, if one person starts an encrypt operation, and then minutes later starts a decrypt operation, you do have to chose to either address it directly by attempting to signal whatever thread of operation somethings going on, or prevent it. This is an edge case, but ultimately if you do nothing that’s just wrong. The fact that it’s an edge case should actually make this easier for you. Just prevent the batch process. Rarely will it be an issue since this probably almost never happens. But when it does, you’ve prevented a possible problem.

But, ultimately it’s up to you. Regardless, there’s no arguing that you respond to everything. Thank you.

[SvanteSpectator]

Hello Givanni,

You obviously have a good understanding of the underlying technical issues here, so thank you for a relevant discussion.

I am now considering (although I am loath to add options and dialogs that many users will be confused by) adding a warning and an option to cancel an ongoing operation. There are still edge cases though.

It’s not reasonable to stop a person from opening an encrypted file, or encrypt a single file, while a larger background operation is in progress. The ongoing process can be time consuming because of the size of a single file, or because of the number of files, or both.

I will think about this… Thank you!

[Author]

Posts