Large encrypted files being created?

The one-off decrypt is not the same as setting an auto-decrypt flag on the folder. The one-off decrypt does indeed leave the original behind, there is after all a very slight risk of some kind of corruption in the process and you wouldn't want an ultra-precious recording getting trashed with no way back.
Hi guys,

I've set Auto-Decrypt on my folders and I'm finding it's currently leaving all the .encrypted files; it's not auto-deleting any in both root folder and "Series" folders.
Same thing happened to me last week, the first time I'd used the auto-unprotect / decrypt functions. The .encrypted files remained in the original folders. Not a problem - I spotted them right away, though I also deleted the associated .mht / thm / iles by mistake, so lost the metadata. :(
I've had this issue too, and I don't have undelete either.

Looking at the code for deleting the .encrypted file when there is no dustbin, it is a simple tdelete of the filename, which in turn passes the filename via the tdelete proc ultimately to trm to do the actual delete. Does trm need to be supplied with the full path (meaning that it can't find the file at present), or is simply the filename sufficient? At present the tdelete proc uses 'path' as an incoming parameter, maybe implying a full path is expected?

Apologies if I'm talking rot......
I don't, no. Should I install it?
Not necessarily, there are just two different code paths depending on whether it is installed or not. I have it installed so that might explain why I'm not seeing the problem.

Apologies if I'm talking rot......

You aren't : ) But $rpath should be fully qualified. I'll remove undelete from my system and see what's going on.
Got it - the set bin part should be inside the if {$dustbin ne ""} clause otherwise it bombs out with a system error.
I will be releasing a new version of the web interface tomorrow and will include this fix in it.
This is fixed in web interface version 0.10.0 which is now in the repository.