SIGNATURE.db3 - 843,181,056 bytes
As it was not possible to move it without exiting NewsBin first, switched to RC1 as well (2 changes - not good for debugging).
Deleting unrared rars now is instantaneous.
Not only that, but the decoding from the cache (creating files after downloading, probably par checking as well) - it is much much faster as well. Previously creating files took significantly longer than downloading them. Now it so much faster, that most of it is done during the downloading of the same file. Previously the download finished first, before PAR counter moved from 0. And that counter now moves maybe 100 times faster.
The whole downloading is so much faster, it (almost?) feels like using the good old NewsBin 6.55
Maybe now the other issues will be less painful too? "Display update pending" - or whatever. It used to be this way: after expanding a post in the download list, most elements, or even all of them where shown as "pending" and even selecting a line did not make it resolved. Several minutes of waiting before it is resolved. So far, it seems to be fixed as well.
And simply deleting a post (a single line) from the download list - it used to throw NewsBin into "unresponding" state for several minutes as well. I hope it was affected as well.
And another issue: moving something to the top if there are already downloaded items - perhaps the backlog will be almost non-existing.
Unfortunately, there is another bad issue when some multi-part rars show up on disk in uppercase as damaged or even 0 length. Usually first parts are ok, but from some point till the end they all are bad.
But it does not happen always. After deleting and re-downloading the same post - everything is OK.
It is difficult to reproduce, but I had several such cases just today. Happened before as well. Maybe this was fixed as well?
descript.ion - maybe it should have a different name, not descript.ion?
descript.ion is supposed to be kept always synchronized with the contents of the directory.
If some software creates, renames, copies, moves, deletes files, it is responsible for updating descript.ion accordingly.
You are aware that file managers such as FAR can show the corresponding to a file description from descript.ion, changing it accordingly as you move from file to file in the list of files.
Not updating descript.ion disrupts that functionality.
On the other hand, if autopar/unrar is switched off, probably descript.ion is mostly OK.
Oh, the renaming issue, the -(0001) etc. files - they may cause descript.ion to go out of sync as well.