I can understand you, I've experienced a similar situation...
I remember that I thought: Perhaps energy wasted and credits lost are the minor loss... What if this task was the key for a healing molecule?

I tried a size which turned out to be 532,721,637 bytes. And - and I think this is crucial - I changed the value stored in client_state.xml to the same value. Just look for an _9 file file with lots of upload attempts - there won't be many around. Just change the nbytes value.

And it uploaded, and the task reported. And, not surprisingly, it was declared invalid with a Validate error.

Which is as it should be. Don't try this at home, kiddies!

This file is actually a compressed text file, so it will be always invalid if you truncate the compressed stream like that, as you mess up the CRC and the stream length etc. So we can't fix this issue this way, only figure out the exact limit of the upload.

I still think that the most straightforward fix is to release this batch as a 3 fragment simulation (it's a 2 fragment batch at the moment as there is -0-2- and -1-2- in their names). This would make 2/3 the processing time of the workunits and the upload size of the result compared to the present ones.

That was my next thought - though it would be tricky to shorten the de-compressed file so that it re-compressed to exactly xxx,000,000.

I agree: the simplest change - assuming they don't have control over their own server - would be to split the processing into thirds, rather than halves. But that would require the management to talk to the researchers, and there's not much sign of that either.

@ Retvari Zoltan:

What archive manager did you use to decompress the file? It's not in a standard gzip or zip format, and I don't see any plaintext clues inside the file itself. My Linux Archive Manager won't open it, even when I try to fool it with .gz / .zip / .7z extensions on the file name.

What archive manager did you use to decompress the file?

WinRAR.

It's not in a standard gzip or zip format, and I don't see any plaintext clues inside the file itself.

True. It's zipped I guess, but it has no filename(s) and other header information inside, as it is unnecessary for a single file.

My Linux Archive Manager won't open it, even when I try to fool it with .gz / .zip / .7z extensions on the file name.

I couldn't open it with WinRAR either.
EDIT:
I hope it's scrambled with a password :)

I got stuck with one of these units

https://www.gpugrid.net/workunit.php?wuid=27079955

516.76 Megs, all that work for nothing!!!!!

I got stuck with one of these units

https://www.gpugrid.net/workunit.php?wuid=27079955

516.76 Megs, all that work for nothing!!!!!

I don't believe this. I couldn't upload the file, so I aborted the upload, and the server still gave me credit. This is just plain weird!!!!!!