Don't run it under bash on Windows. And you can't expect whatever ctrl-c handler is in gcwsieve to work under bash and generate a checkpoint file.

There is no reason to split a minimum range like this, unless you're going to run it on several cores simultaneously. Run it as a single range.

As the "admin in charge", I will not accept 1/32nd sized pieces because I have no way of knowing whether you ran everything properly on those other "missing" pieces. Please do this properly or cancel the reservation.

If your upload fits into the trend of factors found per 100G of sieving, it will be accepted. I'm not expecting miracles, like finding factors where are are none. If I really wanted factors everywhere, I'd start public sieving with a 10M sieve file instead of a 500G sieve file. Then you'd find lots of factors, but it would take longer and not be any better in the long run.

A 500G sieve is shorter than 10M, because so many more factors have been found, causing removals from the sieve file. You're running gc47, here's a few line counts:

24849 gc47_10M.txt
14884 gc47_500G.txt

So we lost 9965 candidates from 10M-500G (which I sieve before this becomes a manual sieving project). Since those candidates are not in the 500G sieve, we're not checking for factors for them, so the sieve runs faster. It only takes one factor to prove that a candidate is composite, we're not trying to find all the factors that exist.