[physfs] Does PHYSFS_close really return 0 on error?

[David Olsen]

Ryan,
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++;
    if (!file)
        printf("Not able to open file requested: %s\n",filename);
    else
        printf("Total Successful Open to Read File Calls: %d\n", total);
    return file;
}

int LOADER::closeFile(PHYSFS_File * file)
{
    int close = PHYSFS_close(file);
    static int total = 0;
    if (close) total++;
    if (!close)
        printf("Unsuccessful closing of file handle!\n");
    else
        printf("Total Successful Close File Calls: %d\n", total);
return close;
}

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
open.
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
double check.

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!
-Dave Olsen

----- 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.
>
> --ryan.
>
>
> ---
> To unsubscribe, send a blank email to physfs-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?4
>
>