[physfs] Does PHYSFS_close really return 0 on error?
jolynsbass at gmail.com
Sun Sep 30 15:53:45 EDT 2007
Thanks for your reply. The two functions that I'm using to opne/close files
look like this:
PHYSFS_file *LOADER::openFileToRead(const char *filename)
PHYSFS_File * file = PHYSFS_openRead(filename);
static int total = 0;
if (file) total++;
printf("Not able to open file requested: %s\n",filename);
printf("Total Successful Open to Read File Calls: %d\n", total);
int LOADER::closeFile(PHYSFS_File * file)
int close = PHYSFS_close(file);
static int total = 0;
if (close) total++;
printf("Unsuccessful closing of file handle!\n");
printf("Total Successful Close File Calls: %d\n", total);
It always returns the same number of succesful closes as opens (e.g. 66 or
so for the first part of my game, 175 total after the second part.) However,
it won't remove one of the .zip files from the search path, claiming that
files are still
I have been using the globbing along with physfsrwops... And it mentioned in
the globbing.c one part where :"/* FIXME: This counts on physfs's allocation
method not changing! */", which is probably not the issue, but I thought I'd
I may just try that mount trick you mentioned. It sounds like it could work
just great for what I need.
Again, thanks for your help!
----- Original Message -----
From: "Ryan C. Gordon" <icculus at icculus.org>
To: <physfs at icculus.org>
Sent: Saturday, September 29, 2007 11:24 PM
Subject: Re: [physfs] Does PHYSFS_close really return 0 on error?
>> So, I have a function that wraps the open/close functions and keeps a
>> tally of succesful opens and closes (according to the return values for
>> those functions. 0 = failure for closing a file.) The tally is always
>> equal! For each successfully opened file there is one corresponding
>> succesful file closing. I have a little thing to output an error message
>> if the return value of PHYFS_close(file) is 0, but it *never* shows up!
>> This seems to indicate that there should really be no files open inside
>> the .zip, and yet the call to remove it from the search path fails
>> because there are.
> Is the code available anywhere? It's worth checking for silly things like:
> if (PHYSFS_close(x) == 0); // whoops, that semicolon is bad!
> opened_files--; // always subtracts, no matter the retval...
> It could be a bug in PhysicsFS, of course, but it's hard to say from here.
> It isn't something that's been reported before, as far as I know.
>> p.s. And the solution does not include having my files named differently.
>> That's not an option (I'm not the one who named the files, and they must
>> remain as they are)
> You can certainly use it that way, but if that's done to work around a
> PhysicsFS limitation, you can try PHYSFS_mount() in the 1.1 branch, so you
> can have multiple archives with the same file names that don't overlap:
> So if a.zip has file.txt, and so does b.zip, you might "mount" them at
> "/one" and "/two" respectively, and then open files with
> PHYSFS_openRead("/one/file.txt") and PHYSFS_openRead("/two/file.txt").
> ...whatever works best for your needs, of course.
> To unsubscribe, send a blank email to physfs-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?4
More information about the physfs