Jump to content
  • Advertisement
Sign in to follow this  
ChaosPhoenix

FILE* going backwards on it's own?!

This topic is 4551 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I decided to throw together a quick file packer to help me with asset management in my game. I've done this a couple times before and never really had this problem come up. The Pak file contents are stored like this: [PAKFile Header(an image, script, whatever] [BinaryData] [PAKFile Header] [BinaryData] etc. Right now I'm storing 2 JPGs in the PAK file, so it looks like such: [JPG1 Name and Bytesize] [JPG1 Binary Data] [JPG2 Name and Bytesize] [JPG2 Binary Data] When I go to load a resource from the PAK file, I just check the name of the resource you are looking for with the 1st header in the PAK file. If that isn't the correct resource I called fseek and move the file pointer to the next header: fseek(pPakFile, tHeader.iBinarySize, SEEK_CUR); then just grab the next header and continue on till the resource is found, all the while checking to see if I'm at the end of file( !feof(pPakFile) ) just incase the resource isn't there. The problem seems to come if I try to load a resource that isn't there. After I seek past the binary data of the last resource in the PAK file, the file pointer jumps BACKWARDS to right before the last resource file header. It NEVER reaches the end of the file. Why in the world would a file pointer move backwards? Here is the code that has the problem:
{
	PAKFileInfo	tFileInfo;
	fseek(m_pCurrentPAK, 0, SEEK_SET);
	while(!feof(m_pCurrentPAK))
	{
		fread(&tFileInfo, sizeof(PAKFileInfo), 1, m_pCurrentPAK);
		if(!stricmp(tFileInfo.cName, szFile))
		{
			fseek(m_pCurrentPAK, tFileInfo.iSize, SEEK_CUR);
			return true;
		}
		fseek(m_pCurrentPAK, tFileInfo.iSize, SEEK_CUR);
	}
	
	return false;
}

Anyone have any clue what is up with behavior?

Share this post


Link to post
Share on other sites
Advertisement
Is it possible that after the last "fseek", you're still off from the EOF by a byte or something like that? Perhaps it is causing "fread" to give a result you don't expect...but I'm not sure what the expected behavior of "fread" is when there's not enough bytes remaining in the file to fill your data structure.

Share this post


Link to post
Share on other sites
if there is less data in the file than requested to be read, then fread return #bytes read
you should be checking that fread returns sizeof(PAKFileInfo)
If it doesn't then it didnt read a record. If it didn't read the record, then the record still has the info from last time,
and so it will jump to the old location again. Not sure if this is where you say it is jumping back to, but
it is something to check.

Share this post


Link to post
Share on other sites
How about trying something like this, you should test each fseek!

If you want to goto the next record you should use an index multipler on the record size to jump to the next record in the following fseek.



int idx = 0; // start at byte 0 to read first, then += 1 for next record
int x; // TRUE / FALSE test this.

if(fseek(stream,(int)idx*sizeof(Rec),SEEK_SET)==0)
x = fread(usr,sizeof(Rec),1,stream);



BTW: if your not doing this when writting to the file, then you could be overwritting the same record over and over.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!