logrotate bug?

I have been mailing myself logs for a while, but just ran into a problem because of a process that cannot HUP its log. (I realize thats why they implemented the "copytruncate" option in the first place)

When I use logrotate with "copytruncate" and "compress" there is a problem. The "myScript" log is rotated to "myScript.1", at which point the "postrotate" directives are executed, and finally the "myScript.1" file is gzipped.

My problem is that I am relying on the "postrotate" stuff to send me the gzipped log. I do this for all my other HUP-able logs, and it works fine. The problem as I see it is that logrotate thinks it's done rotating as soon as it has created the .1 file. However, since I am not controlling the compression, but logrotate IS, the compression should also be considered part of the "rotation"... Unfortunately, since I am looking for a .1.gz file, and it doesnt exist as of the postrotate arguments, I cant send it.

I made an attempt at removing the compress option from logrotate, and putting the gzipping in my postrotate arguments, but that went south too. The problem is that when the next rotation happens, logrotate expects to see a .1 file, doesnt, and so doesnt rotate it to .2... when the original is rolled to the .1, and I then gzip it, it fails to overwrite the .1.gz file that already exists.

I realize that I could put N lines of "if .N exists, rotate to .N+1" in my prerotate arguments, but that seems like a pathetic workaround.

Any ideas?