Restore Point reset while mask processing

I've some trouble with the restore file.
I'm losing all my progress on the current charset when I quit hashcat in the first ~15 seconds.

Further analysis has shown, that the current position within the specific charset of the maskfile is 0 while the mask is processed.

The status view looks like this:
Progress.......:   4041834496/8031810176 (50.32%)
Rejected.......:   0/4041834496 (0.00%)
Restore.Point..: 0/308915776 (0.00%)

After the mask is processed the restore point gets loadeds and saved correctly

Progress.......:   4044931072/8031810176 (50.36%)
Rejected.......:   0/4044931072 (0.00%)
Restore.Point..: 155574272/308915776 (50.36%)

When I quit hashcat while the mask is still processed the restore point 0 is saved to the file and the progress is lost.

Question to the devs: Would it need a big efford to change to order of those operations?
Interesting find. Since this sounds like a enhancement or bugfix, you might get better traction by opening a Trac ticket.
To me what you are describing above doesn't sound like a bug.

What oclHashcat really does is update the restore point as soon as it is safe to do so: mark the keyspace unit (KU) as done if and only if it is (completely) done.
It cannot mark it as done when the current keyspace unit (CURKU) is not finished yet (otherwise it could happen that it skips keyspace and some hashes that should crack do not).

But hashcat stores the position 0 even to the restore file in this timespan.
Phil, I get the feeling the OP is trying to say this: Let's say we have an aborted session, properly saved with a restore point at, say, 50%. Then we resume it. Now, within 15 seconds, we cancel that.

And at this point the previously working restore point at 50% is blown away. The file is now worthless.
Definitely happens exactly as magnum has outlined. I lost quite a few sessions due to this while learning oclhashcat so it's not just v1.37 that's affected. Dunno why I never thought to raise it in trac though. Sorry about that.