After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 423951 - GMime 2.2.4 and 2.2.5 -- g_mime_stream_reset() on GMimeStreamFile not working correctly
GMime 2.2.4 and 2.2.5 -- g_mime_stream_reset() on GMimeStreamFile not working...
Status: RESOLVED FIXED
Product: gmime
Classification: Other
Component: general
2.2.x
Other All
: Normal normal
: ---
Assigned To: Jeffrey Stedfast
Jeffrey Stedfast
Depends on:
Blocks:
 
 
Reported: 2007-03-28 23:54 UTC by Calin Culianu
Modified: 2007-03-29 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Calin Culianu 2007-03-28 23:54:15 UTC 
Please describe the problem:
Jeffrey Stedfast knows about this bug already, but I am creating a ticket anyway for completeness.  Basically g_mime_stream_reset() doesn't reset the stream position, leading to streams basically having no data in them after using them to completion and then calling reset.


Steps to reproduce:
1. Use a GMimeStreamFile, read it till the end.
2. reset the stream
3. Not able to read data anymore (stream acts like eof)

(Note I am going on Jeff's description of the bug and not actualy experience)

Actual results:
Can't read anymore data from stream -- it's EOFd.

Expected results:
File position should be at zero and should be able to read data.

Does this happen every time?
Yes.

Other information:
Nope.
Comment 1 Calin Culianu 2007-03-29 00:29:20 UTC 
PS: My description of how to reproduce this bug might not be entirely correct -- I created this ticket at Jeff's behest..
Comment 2 Calin Culianu 2007-03-29 00:33:29 UTC 
PPS: I think it requires you to actually open the stream with g_mime_stream_*_new_with_bounds(), or g_mime_stream_substream() with a nonzero start in order to trigger the bug.
Comment 3 Jeffrey Stedfast 2007-03-29 01:23:30 UTC 
comment #2 would be correct :)

streams with beginning offset of 0 were fine because lseek() or fseek() (depending on the file stream backing) would obviously return 0 for:

lseek (fd, start, SEEK_SET);

anyways, this is now fixed in the emergency 2.2.6 release