[physfs] Getting every instance of overlapping files
Haydn Harach
hharach at gmail.com
Tue Sep 2 22:00:15 EDT 2014
Searching the new .dll, which I'm confident was compiled using a
version of physfs.h and physfs.c that had closeMulti and not
closeList, I can confirm that the .dll does not contain closeMulti,
but does contain closeList.
On Tue, Sep 2, 2014 at 5:29 PM, Tim Čas <darkuranium at gmail.com> wrote:
> Can you grep the new DLL for closeList and closeMulti, to check which
> symbols are inside? (nm would be better if you have access to FreeBSD,
> or maybe Linux --- the latter's nm might also work with 64-bit DLLs).
>
> On 3 September 2014 00:12, Haydn Harach <hharach at gmail.com> wrote:
>> I rebuilt PhysFS just to be sure, and copied the new DLL into my
>> project, and I'm still getting undefined reference to
>> PHYSFS_closeMulti.
>>
>> On Sun, Aug 31, 2014 at 11:29 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>> Sorry for the late reply, it's been a busy weekend.
>>>
>>> Well, grepping finds closeList, but *NOT* closeMulti --- something
>>> tells me I have your old DLLs here (since they contain the old
>>> symbol). The sources do contain closeMulti, though.
>>>
>>> Point is, perhaps it's failing to find your symbols because you're
>>> been running this with an outdated DLL? (as in, one which exports
>>> closeList instead of closeMulti that your header defines).
>>>
>>> (Trivia: Apparently, FreeBSD's `nm` utility can handle 64-bit Windows
>>> DLLs just fine, while the MSYS one cannot. Ah, beautiful irony.)
>>>
>>> On 28 August 2014 16:05, Haydn Harach <hharach at gmail.com> wrote:
>>>> Sorry, I forgot to mention that I renamed PHYSFS_closeList to
>>>> PHYSFS_closeMulti in order to match the naming convention I set for
>>>> PHYSFS_openReadMulti. I kept calling it closeList here to match the
>>>> code I posted earlier.
>>>>
>>>> In hindsight that was probably pretty important to mention <.<
>>>>
>>>> On Thu, Aug 28, 2014 at 8:00 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>>>> Sorry for the double post, but I've just noticed that your binary
>>>>> files that you've sent me *DO* contain PHYSFS_closeList *somewhere*.
>>>>>
>>>>> I can't actually tell if it's an exported symbol because MSYS' `nm`
>>>>> doesn't seem to work with 64-bit DLLs; might be just debugging
>>>>> symbols... The utility which found that was grep.
>>>>> Same for PHYSFS_openReadMulti (both of this holds for all the three
>>>>> files --- *.dll, *.a, *.dll.a).
>>>>>
>>>>> On 28 August 2014 15:54, Tim Čas <darkuranium at gmail.com> wrote:
>>>>>> Huh, what closeList? I can't find that in either PhysFS 2.0.3 sources
>>>>>> *or* your modifications (grepped both, recursively).
>>>>>>
>>>>>> And yes, the DLL needs to be in the same directory as the executable
>>>>>> for Windows to find it.
>>>>>>
>>>>>> On 28 August 2014 08:04, Haydn Harach <hharach at gmail.com> wrote:
>>>>>>> I'm using physfs-2.0.3.
>>>>>>>
>>>>>>> I'm putting the .dll in the same directory as the code::blocks
>>>>>>> project, which is where it expects you to put .dll's. I tried putting
>>>>>>> it into the "bin/debug" folder, which I assumed was incorrect, but lo
>>>>>>> and behold it finds the function now. I guess if you have .dll's
>>>>>>> there, it uses those instead of the ones stored with the project file.
>>>>>>>
>>>>>>> So, PHYSFS_openReadMulti works* now, but it still can't find
>>>>>>> PHYSFS_closeList at all (wont even compile).
>>>>>>>
>>>>>>> And by works, I mean it technically compiles and doesn't crash. It
>>>>>>> doesn't actually work, it still only finds a single instance of a file
>>>>>>> that I distinctly put into multiple places for testing.
>>>>>>>
>>>>>>> On Wed, Aug 27, 2014 at 8:40 AM, Haydn Harach <hharach at gmail.com> wrote:
>>>>>>>> I'm using physfs-2.0.3.
>>>>>>>>
>>>>>>>> I'm putting the .dll in the same directory as the code::blocks project,
>>>>>>>> which is where it expects you to put .dll's. I tried putting it into the
>>>>>>>> "bin/debug" folder, which I assumed was incorrect, but lo and behold it
>>>>>>>> finds the function now. I guess if you have .dll's there, it uses those
>>>>>>>> instead of the ones stored with the project file.
>>>>>>>>
>>>>>>>> So, PHYSFS_openReadMulti works* now, but it still can't find
>>>>>>>> PHYSFS_closeList at all (wont even compile).
>>>>>>>>
>>>>>>>> And by works, I mean it technically compiles and doesn't crash. It doesn't
>>>>>>>> actually work, it still only finds a single instance of a file that I
>>>>>>>> distinctly put into multiple places for testing.
>>>>>>>>
>>>>>>>> PHYSFS_file** files = PHYSFS_openReadMulti("module.data");
>>>>>>>> int num = 0;
>>>>>>>> for (PHYSFS_file** i = files; *i != NULL; ++i)
>>>>>>>> {
>>>>>>>> ++num;
>>>>>>>> }
>>>>>>>> cout << "Found " << num << " copies of 'module.data'\n";
>>>>>>>>
>>>>>>>> From this I get "Found 1 copies of 'module.data'", when I know that there
>>>>>>>> should be 3.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Aug 27, 2014 at 8:29 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Which version of PhysFS is that based on? (so that I can download the
>>>>>>>>> other files)
>>>>>>>>>
>>>>>>>>> Also, you mentioned that it doesn't find the symbol in the DLL ---
>>>>>>>>> where are you putting said DLL? Is it in the same directory as the
>>>>>>>>> program? (it might be finding a different, older DLL)
>>>>>>>>>
>>>>>>>>> On 27 August 2014 16:10, Haydn Harach <hharach at gmail.com> wrote:
>>>>>>>>> > I tried using "-static -lphysfs -dynamic" instead of "-lphysfs", but now
>>>>>>>>> > it
>>>>>>>>> > breaks everything else (namely, SDL).
>>>>>>>>> >
>>>>>>>>> > Here's a link to the files I've modified: physfs.h, physfs.c,
>>>>>>>>> > libphysfs.a,
>>>>>>>>> > libphysfs.dll, and libphysfs.dll.a:
>>>>>>>>> >
>>>>>>>>> > https://www.dropbox.com/s/4jjxhxodoxvlbr9/physfs%20modifications.zip?dl=0
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Wed, Aug 27, 2014 at 8:01 AM, Tim Čas <darkuranium at gmail.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Yes, linking with that will link with the DLL. Try adding '-static'
>>>>>>>>> >> before
>>>>>>>>> >> '-lphysfs' and '-dynamic' after to link with the static lib.
>>>>>>>>> >>
>>>>>>>>> >> Can you upload the DLL and/or the sources somewhere so that I can take
>>>>>>>>> >> a
>>>>>>>>> >> look with 'nm' and try compiling myself?
>>>>>>>>> >>
>>>>>>>>> >> On Aug 27, 2014 3:51 PM, "Haydn Harach" <hharach at gmail.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> I'm just linking with -lphysfs, like you said. I don't have MSYS.
>>>>>>>>> >>> The
>>>>>>>>> >>> only source file I modified was physfs.c, I didn't add any.
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Wed, Aug 27, 2014 at 7:45 AM, Tim Čas <darkuranium at gmail.com>
>>>>>>>>> >>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> How are you using libphysfs.a? I've often found that linking with
>>>>>>>>> >>>> just
>>>>>>>>> >>>> -lphysfs tends to make MinGW link with the DLL instead of the
>>>>>>>>> >>>> library.
>>>>>>>>> >>>>
>>>>>>>>> >>>> If you have MSYS, you can also try this to find out if the DLL
>>>>>>>>> >>>> exports
>>>>>>>>> >>>> the symbol (which would indicate that the problem is elsewhere):
>>>>>>>>> >>>> $ nm libphysfs.dll | grep openRead
>>>>>>>>> >>>>
>>>>>>>>> >>>> Oh and, I just had a thought --- when you added PHYSFS_openReadMulti,
>>>>>>>>> >>>> did you create any new source files? If you did, you have to run
>>>>>>>>> >>>> cmake
>>>>>>>>> >>>> again for it to recognize the new files? It is entirely possible that
>>>>>>>>> >>>> it's not compiling in said new file (though that wouldn't quite
>>>>>>>>> >>>> explain why the symbol exists in the static library).
>>>>>>>>> >>>>
>>>>>>>>> >>>> On 27 August 2014 15:21, Haydn Harach <hharach at gmail.com> wrote:
>>>>>>>>> >>>> > It creates "libphysfs.a", "libphysfs.dll", and "libphysfs.dll.a"
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > I've tried using both the .dll and the non-.dll version of the .a
>>>>>>>>> >>>> > library,
>>>>>>>>> >>>> > they both have the issues. Interestingly, when using libphysfs.a,
>>>>>>>>> >>>> > it
>>>>>>>>> >>>> > still
>>>>>>>>> >>>> > requires libphysfs.dll, even before I started modifying the source
>>>>>>>>> >>>> > code.
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > On Wed, Aug 27, 2014 at 7:17 AM, Tim Čas <darkuranium at gmail.com>
>>>>>>>>> >>>> > wrote:
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> And did you also compile the DLLs, or did you only compile the
>>>>>>>>> >>>> >> static
>>>>>>>>> >>>> >> (*.a) library? MinGW tends to create one file for static builds
>>>>>>>>> >>>> >> (foo.a
>>>>>>>>> >>>> >> or libfoo.a) and two files for dynamic builds ({lib,}foo.dll.a and
>>>>>>>>> >>>> >> {lib,}foo.dll) --- it seems that you've perhaps only created the
>>>>>>>>> >>>> >> static library?
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> On 27 August 2014 13:05, Haydn Harach <hharach at gmail.com> wrote:
>>>>>>>>> >>>> >> > Yes, I did replace the dll's. From what I gather,
>>>>>>>>> >>>> >> > `PHYSFS_openReadMulti` is
>>>>>>>>> >>>> >> > present in `physfs.a` but not in `physfs.dll`, and
>>>>>>>>> >>>> >> > `PHYSFS_closeList` is
>>>>>>>>> >>>> >> > not
>>>>>>>>> >>>> >> > present in `physfs.a` (and presumably not in `physfs.dll`,
>>>>>>>>> >>>> >> > either).
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> > I'm compiling both physfs and my app using MinGW-W64.
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> > On Wed, Aug 27, 2014 at 3:39 AM, Tim Čas <darkuranium at gmail.com>
>>>>>>>>> >>>> >> > wrote:
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >> Did you replace the DLLs after compiling? The application might
>>>>>>>>> >>>> >> >> still
>>>>>>>>> >>>> >> >> be
>>>>>>>>> >>>> >> >> using the old one if you forgot to do that.
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >> On 27 August 2014 10:10, Haydn Harach <hharach at gmail.com>
>>>>>>>>> >>>> >> >> wrote:
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>> PHYSFS_openReadMulti compiles just fine, but then my app
>>>>>>>>> >>>> >> >>> crashes
>>>>>>>>> >>>> >> >>> because
>>>>>>>>> >>>> >> >>> it can't find it in physfs.dll. So, it found it in the .a,
>>>>>>>>> >>>> >> >>> but
>>>>>>>>> >>>> >> >>> not in
>>>>>>>>> >>>> >> >>> the
>>>>>>>>> >>>> >> >>> .dll? what am I doing wrong compiling physfs? >.<
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>> On Tue, Aug 26, 2014 at 9:51 AM, Haydn Harach
>>>>>>>>> >>>> >> >>> <hharach at gmail.com>
>>>>>>>>> >>>> >> >>> wrote:
>>>>>>>>> >>>> >> >>>>
>>>>>>>>> >>>> >> >>>> Now I'm having trouble rebuilding the project. I'm trying to
>>>>>>>>> >>>> >> >>>> use a
>>>>>>>>> >>>> >> >>>> code::blocks project which I generated with cmake, changing
>>>>>>>>> >>>> >> >>>> only
>>>>>>>>> >>>> >> >>>> the
>>>>>>>>> >>>> >> >>>> 2 files
>>>>>>>>> >>>> >> >>>> (physfs.c and physfs.h). It compiles and builds just fine,
>>>>>>>>> >>>> >> >>>> but
>>>>>>>>> >>>> >> >>>> I'm
>>>>>>>>> >>>> >> >>>> getting
>>>>>>>>> >>>> >> >>>> "undefined reference to PHYSFS_closeList" now. What did I do
>>>>>>>>> >>>> >> >>>> wrong?
>>>>>>>>> >>>> >> >>>>
>>>>>>>>> >>>> >> >>>>
>>>>>>>>> >>>> >> >>>> On Mon, Aug 25, 2014 at 6:55 PM, Haydn Harach
>>>>>>>>> >>>> >> >>>> <hharach at gmail.com>
>>>>>>>>> >>>> >> >>>> wrote:
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> Alrighty, here are the additions I've made to my physfs.c:
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> PHYSFS_File **PHYSFS_openReadMulti(const char *_fname)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> char *fname;
>>>>>>>>> >>>> >> >>>>> size_t len;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> BAIL_IF_MACRO(_fname == NULL, ERR_INVALID_ARGUMENT, 0);
>>>>>>>>> >>>> >> >>>>> len = strlen(_fname) + 1;
>>>>>>>>> >>>> >> >>>>> fname = (char *) __PHYSFS_smallAlloc(len);
>>>>>>>>> >>>> >> >>>>> BAIL_IF_MACRO(fname == NULL, ERR_OUT_OF_MEMORY, 0);
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> FileHandle** ret = NULL;
>>>>>>>>> >>>> >> >>>>> unsigned int retcount = 0;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> if (sanitizePlatformIndependentPath(_fname, fname))
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> int fileExists = 0;
>>>>>>>>> >>>> >> >>>>> DirHandle *i = NULL;
>>>>>>>>> >>>> >> >>>>> fvoid *opaque = NULL;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> __PHYSFS_platformGrabMutex(stateLock);
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> GOTO_IF_MACRO(!searchPath, ERR_NO_SUCH_PATH,
>>>>>>>>> >>>> >> >>>>> openReadEnd);
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> /* !!! FIXME: Why aren't we using a for loop here?
>>>>>>>>> >>>> >> >>>>> */
>>>>>>>>> >>>> >> >>>>> i = searchPath;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> do
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> char *arcfname = fname;
>>>>>>>>> >>>> >> >>>>> if (verifyPath(i, &arcfname, 0))
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> opaque = i->funcs->openRead(i->opaque,
>>>>>>>>> >>>> >> >>>>> arcfname,
>>>>>>>>> >>>> >> >>>>> &fileExists);
>>>>>>>>> >>>> >> >>>>> if (opaque)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> // We found a valid file, let's prepare
>>>>>>>>> >>>> >> >>>>> it.
>>>>>>>>> >>>> >> >>>>> FileHandle* h =
>>>>>>>>> >>>> >> >>>>> (FileHandle*)allocator.Malloc(sizeof(FileHandle));
>>>>>>>>> >>>> >> >>>>> if (h == NULL)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> i->funcs->fileClose(opaque);
>>>>>>>>> >>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY,
>>>>>>>>> >>>> >> >>>>> openReadEnd);
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>> memset(h, 0, sizeof(FileHandle));
>>>>>>>>> >>>> >> >>>>> h->opaque = opaque;
>>>>>>>>> >>>> >> >>>>> h->forReading = 1;
>>>>>>>>> >>>> >> >>>>> h->dirHandle = i;
>>>>>>>>> >>>> >> >>>>> h->funcs = i->funcs;
>>>>>>>>> >>>> >> >>>>> h->next = openReadList;
>>>>>>>>> >>>> >> >>>>> openReadList = h;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> // Add the file to the list
>>>>>>>>> >>>> >> >>>>> FileHandle** temp =
>>>>>>>>> >>>> >> >>>>> (FileHandle**)allocator.Malloc(sizeof(FileHandle) *
>>>>>>>>> >>>> >> >>>>> (retcount +
>>>>>>>>> >>>> >> >>>>> 1));
>>>>>>>>> >>>> >> >>>>> if (temp == NULL)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> allocator.Free(h);
>>>>>>>>> >>>> >> >>>>> i->funcs->fileClose(opaque);
>>>>>>>>> >>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY,
>>>>>>>>> >>>> >> >>>>> openReadEnd);
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>> if (ret != NULL)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> memcpy(temp, ret, sizeof(FileHandle)
>>>>>>>>> >>>> >> >>>>> *
>>>>>>>>> >>>> >> >>>>> retcount);
>>>>>>>>> >>>> >> >>>>> allocator.Free(ret);
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>> temp[retcount] = h;
>>>>>>>>> >>>> >> >>>>> ++retcount;
>>>>>>>>> >>>> >> >>>>> ret = temp;
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>> } /* if */
>>>>>>>>> >>>> >> >>>>> i = i->next;
>>>>>>>>> >>>> >> >>>>> } while ((i != NULL) && (!fileExists));
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> // Add a null terminator to the list
>>>>>>>>> >>>> >> >>>>> if (ret != NULL)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> FileHandle** temp =
>>>>>>>>> >>>> >> >>>>> (FileHandle**)allocator.Malloc(sizeof(FileHandle) *
>>>>>>>>> >>>> >> >>>>> (retcount +
>>>>>>>>> >>>> >> >>>>> 1));
>>>>>>>>> >>>> >> >>>>> if (temp == NULL)
>>>>>>>>> >>>> >> >>>>> GOTO_MACRO(ERR_OUT_OF_MEMORY, openReadEnd);
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> memcpy(temp, ret, sizeof(FileHandle) *
>>>>>>>>> >>>> >> >>>>> retcount);
>>>>>>>>> >>>> >> >>>>> allocator.Free(ret);
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> temp[retcount] = NULL;
>>>>>>>>> >>>> >> >>>>> ret = temp;
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> openReadEnd:
>>>>>>>>> >>>> >> >>>>> __PHYSFS_platformReleaseMutex(stateLock);
>>>>>>>>> >>>> >> >>>>> } /* if */
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> __PHYSFS_smallFree(fname);
>>>>>>>>> >>>> >> >>>>> return ret;
>>>>>>>>> >>>> >> >>>>> } /* PHYSFS_openReadMulti */
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> int PHYSFS_closeList(PHYSFS_file** list)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> int retval = 1;
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> for (PHYSFS_file** i = list; *i != NULL; ++i)
>>>>>>>>> >>>> >> >>>>> {
>>>>>>>>> >>>> >> >>>>> if (PHYSFS_close(*i) == 0)
>>>>>>>>> >>>> >> >>>>> retval = 0;
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> allocator.Free(list);
>>>>>>>>> >>>> >> >>>>> return retval;
>>>>>>>>> >>>> >> >>>>> }
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> Is there anything not immediately obvious that I'm missing?
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>> On Mon, Aug 25, 2014 at 6:11 PM, Edward Rudd
>>>>>>>>> >>>> >> >>>>> <urkle at outoforder.cc>
>>>>>>>>> >>>> >> >>>>> wrote:
>>>>>>>>> >>>> >> >>>>>>
>>>>>>>>> >>>> >> >>>>>> On Aug 25, 2014, at 8:06 PM, Haydn Harach
>>>>>>>>> >>>> >> >>>>>> <hharach at gmail.com>
>>>>>>>>> >>>> >> >>>>>> wrote:
>>>>>>>>> >>>> >> >>>>>>
>>>>>>>>> >>>> >> >>>>>> > Looking at PHYSFS_openRead() in physfs.c, I've found this
>>>>>>>>> >>>> >> >>>>>> > little
>>>>>>>>> >>>> >> >>>>>> > snippet:
>>>>>>>>> >>>> >> >>>>>> >
>>>>>>>>> >>>> >> >>>>>> > do
>>>>>>>>> >>>> >> >>>>>> > {
>>>>>>>>> >>>> >> >>>>>> > char *arcfname = fname;
>>>>>>>>> >>>> >> >>>>>> > if (verifyPath(i, &arcfname, 0))
>>>>>>>>> >>>> >> >>>>>> > {
>>>>>>>>> >>>> >> >>>>>> > opaque = i->funcs->openRead(i->opaque,
>>>>>>>>> >>>> >> >>>>>> > arcfname,
>>>>>>>>> >>>> >> >>>>>> > &fileExists);
>>>>>>>>> >>>> >> >>>>>> > if (opaque)
>>>>>>>>> >>>> >> >>>>>> > break;
>>>>>>>>> >>>> >> >>>>>> > } /* if */
>>>>>>>>> >>>> >> >>>>>> > i = i->next;
>>>>>>>>> >>>> >> >>>>>> > } while ((i != NULL) && (!fileExists));
>>>>>>>>> >>>> >> >>>>>> >
>>>>>>>>> >>>> >> >>>>>> > Now, from what I can see, this loop goes through all the
>>>>>>>>> >>>> >> >>>>>> > paths,
>>>>>>>>> >>>> >> >>>>>> > and
>>>>>>>>> >>>> >> >>>>>> > the first one that satisfies the function and returns
>>>>>>>>> >>>> >> >>>>>> > some
>>>>>>>>> >>>> >> >>>>>> > data
>>>>>>>>> >>>> >> >>>>>> > (from the
>>>>>>>>> >>>> >> >>>>>> > openRead function) and causes 'opaque' to not be NULL,
>>>>>>>>> >>>> >> >>>>>> > and
>>>>>>>>> >>>> >> >>>>>> > thus
>>>>>>>>> >>>> >> >>>>>> > breaks out
>>>>>>>>> >>>> >> >>>>>> > of the loop.
>>>>>>>>> >>>> >> >>>>>> >
>>>>>>>>> >>>> >> >>>>>> > So, if I replaced "if (opaque) break;" with "if (opaque)
>>>>>>>>> >>>> >> >>>>>> > someVector.emplace_back(opaque, i);", then did some
>>>>>>>>> >>>> >> >>>>>> > cleanup
>>>>>>>>> >>>> >> >>>>>> > to
>>>>>>>>> >>>> >> >>>>>> > ensure that I
>>>>>>>>> >>>> >> >>>>>> > have a vector of FileHandle's instead of one, and return
>>>>>>>>> >>>> >> >>>>>> > that,
>>>>>>>>> >>>> >> >>>>>> > this should
>>>>>>>>> >>>> >> >>>>>> > be exactly what I'm looking for, yes?
>>>>>>>>> >>>> >> >>>>>>
>>>>>>>>> >>>> >> >>>>>> More or less, yes that would be exactly what you were
>>>>>>>>> >>>> >> >>>>>> looking
>>>>>>>>> >>>> >> >>>>>> for.
>>>>>>>>> >>>> >> >>>>>> _______________________________________________
>>>>>>>>> >>>> >> >>>>>> physfs mailing list
>>>>>>>>> >>>> >> >>>>>> physfs at icculus.org
>>>>>>>>> >>>> >> >>>>>> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>>
>>>>>>>>> >>>> >> >>>>
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>> _______________________________________________
>>>>>>>>> >>>> >> >>> physfs mailing list
>>>>>>>>> >>>> >> >>> physfs at icculus.org
>>>>>>>>> >>>> >> >>> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >> >>>
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >> _______________________________________________
>>>>>>>>> >>>> >> >> physfs mailing list
>>>>>>>>> >>>> >> >> physfs at icculus.org
>>>>>>>>> >>>> >> >> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >> >>
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> > _______________________________________________
>>>>>>>>> >>>> >> > physfs mailing list
>>>>>>>>> >>>> >> > physfs at icculus.org
>>>>>>>>> >>>> >> > http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >> >
>>>>>>>>> >>>> >> _______________________________________________
>>>>>>>>> >>>> >> physfs mailing list
>>>>>>>>> >>>> >> physfs at icculus.org
>>>>>>>>> >>>> >> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > _______________________________________________
>>>>>>>>> >>>> > physfs mailing list
>>>>>>>>> >>>> > physfs at icculus.org
>>>>>>>>> >>>> > http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>> >
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> physfs mailing list
>>>>>>>>> >>>> physfs at icculus.org
>>>>>>>>> >>>> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> physfs mailing list
>>>>>>>>> >>> physfs at icculus.org
>>>>>>>>> >>> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>>
>>>>>>>>> >>
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> physfs mailing list
>>>>>>>>> >> physfs at icculus.org
>>>>>>>>> >> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > physfs mailing list
>>>>>>>>> > physfs at icculus.org
>>>>>>>>> > http://icculus.org/mailman/listinfo/physfs
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> physfs mailing list
>>>>>>>>> physfs at icculus.org
>>>>>>>>> http://icculus.org/mailman/listinfo/physfs
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> physfs mailing list
>>>>>>> physfs at icculus.org
>>>>>>> http://icculus.org/mailman/listinfo/physfs
>>>>> _______________________________________________
>>>>> physfs mailing list
>>>>> physfs at icculus.org
>>>>> http://icculus.org/mailman/listinfo/physfs
>>>> _______________________________________________
>>>> physfs mailing list
>>>> physfs at icculus.org
>>>> http://icculus.org/mailman/listinfo/physfs
>>> _______________________________________________
>>> physfs mailing list
>>> physfs at icculus.org
>>> http://icculus.org/mailman/listinfo/physfs
>> _______________________________________________
>> physfs mailing list
>> physfs at icculus.org
>> http://icculus.org/mailman/listinfo/physfs
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
More information about the physfs
mailing list