Because I am working on Windows and have currently no Linux machine available, I tried different methods to make the compressed table file:
Firstly, using a windows utility called stuffit a got a file called "test.gz" (rather strange when looked in an editor)
Secondly, because your file is indeed a CSV file using:

CREATE TABLE tz (

  c1 VARCHAR(100) NOT NULL,

  c2 VARCHAR(100) NOT NULL

)

ENGINE=CONNECT table_type=CSV COMPRESS=1 file_name='test.tsv.gz';

insert into tz values('1','test1'),('2','test2');

Thirdly under cygwin, doing your method with gzip.
These 3 files are different. I attached them after renaming the second one as 'test.tsv2.gz'.
Now testing:

CREATE TABLE test (

  c1 VARCHAR(100) NOT NULL field_format='%n%[^,]%n',

  c2 VARCHAR(100) NOT NULL field_format=',%n%s%n'

)

ENGINE=CONNECT table_type=FMT COMPRESS=1 file_name='test.tsv.gz';

Select * from test;

I always got the correct display:

No error with all three files.
Could you attach your table file so I can test it? I could you test the files I have attached to see if it produces an error?

I've tested all the provided files, none of them worked!
Here is how Linux sees them:
test.gz: gzip compressed data, was "test.tsv", from FAT filesystem (MS-DOS, OS/2, NT), last modified: Wed May 6 09:00:08 2015
test.tsv2.gz: gzip compressed data, from NTFS filesystem (NT)
test.tsv.gz: gzip compressed data, was "test.tsv", from Unix, last modified: Wed May 6 10:33:58 2015

I also see this message in the error_log: "rnd_next CONNECT:"

Here is the trace:

external_lock: this=0x7f34b28f5420 thd=0x7f2f3ec39008 xp=0x7f2d736392c0 g=0x7f348149f000 lock_type=0

0x7f34b28f5420 check_mode: cmdtype=0

Cmd=select * from fed.test LIMIT 0, 1000

New mode=10

Calling CntCheckDB db=fed cras=0

external_lock: rc=0

0x7f34b28f5420 In info: flag=18 valid_info=0

XTAB: making new TABLE test (null)

GetFileLength: fn=/tmp/test.gz h=2861

GetFileLength: fn=/tmp/test.gz h=2861

Estimating lines len=300 ending=1/navglen=23 MaxSize14

rnd_init: this=0x7f34b28f5420 scan=1 xmod=10 alter=0

ColDB: am=33 colname=c1 tabname=test num=0

cdp(1).Name=c1 cp=(nil)

 making new CSVCOL C1 c1 at 0x7f2da4400538

colp=0x7f2da4400538

ColDB: am=33 colname=c2 tabname=test num=0

cdp(2).Name=c2 cp=(nil)

 making new CSVCOL C2 c2 at 0x7f2da44005f8

colp=0x7f2da44005f8

DOS OpenDB: tdbp=0x7f2da44003f8 tdb=R312 use=0 mode=10

SubAllocating a buffer of 211 bytes

OpenDos: R312 mode=10 To_Line=0x7f2da4400a00

GetFileLength: fn=/tmp/test.gz h=7669

rnd_next CONNECT:

GEM(0):

external_lock: this=0x7f34b28f5420 thd=0x7f2f3ec39008 xp=0x7f2d736392c0 g=0x7f348149f000 lock_type=2

ZIP CloseDB: closing /tmp/test.gz rc=0

Thanks,

What you did shows that everything works fine on Windows but fail on Linux. Right now I can't do much not having an available Linux to do some tests. The trace you made does not show much except the line:

GEM(0):

It shows that an error condition was raised but probably without real cause as no error message was made.
Waiting for my reintalling a Linux system on my machine, two things you can do:
1) Attach your own test.tbl.gz file here so I can test it on Windows
2) Execute the scripts of my last comment on Linux to see what it does.
I don't expect much from this but one never knows...

Which script are you referring to?
The create table ?

Younes

Yes, all my sample code.

Just did with the same result.
Do you want me to send you a truss result?

What do you mean "same result"? Mine or yours?

I tried again, this time on a different box running CentOS6 (CentOS release 6.6 (Final)), and it worked!!!!
So, the problem seems to be with CentOS 7 (CentOS Linux release 7.1.1503 (Core)).

I'll keep digging...

Thanks,

I meant still errors out on Centos7.

Younes

Which library do you use read the compressed files?

y

gzip

I've also hit this bug.

I can confirm that it works fine with CentOS 6 but not with 7.

This seems to be an old issue probably not occuring anymore.