# Seek() in GzipReader

**URL:** <https://www.ruby-forum.com/t/seek-in-gzipreader/121563>\
**Category:** Ruby\
**Created:** [November 28, 2007, 10:52pm UTC](https://www.ruby-forum.com/t/seek-in-gzipreader/121563 "2007-11-28T22:52:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 28, 2007, 10:52pm UTC](https://www.ruby-forum.com/t/seek-in-gzipreader/121563/1 "2007-11-28T22:52:04Z")

</div>

Looking at RubyDoc for GzipReader (  
[http://ruby-doc.org/core/classes/Zlib/GzipReader.html](http://ruby-doc.org/core/classes/Zlib/GzipReader.html)) I notice that  
there  
is no seek() method available, as with IO.seek() or IO.pos=.

Does anyone have any ideas on how to do a traditional seek through a  
gzip’ed  
file using GzipReader?

I notice that there is GzipReader.lineno=(), but, as per this discussion  
from about 2 years ago ([IO.lineno= not behaving as expected - Ruby - Ruby-Forum](http://www.ruby-forum.com/topic/5603)), the  
purpose  
of lineno=() eludes me (since it doesn’t actually modify the position  
for  
the next read operation).

I should clarify that the files being read are quite large (as in  
several  
gigabytes), and so loading up the entire file into an Array in memory is  
not  
an option for me.

regards,  
Matt

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [November 29, 2007, 12:01am UTC](https://www.ruby-forum.com/t/seek-in-gzipreader/121563/2 "2007-11-29T00:01:10Z")

</div>

I realize, now, that there is probably no “meaningful” way to seek  
through a  
compressed file. It would require starting at the beginning of the  
file,  
and counting the bytes as it was uncompressed until the seek point was  
reached … which rather defeats one of the major benefits of seeking in  
the  
first place (to quickly navigate a file).

I could see, perhaps, a mechanism for leaving position bookmarks as one  
uses  
the file, that can then be used later to faster seeking…

Anyway, sorry for the spam!

Matt