[A5] al_read_directory() odd behavior
So what I'm doing is this. I create an FS_ENTRY with a path to my lib folder, then open the directory and try to read the files inside. I've confirmed that the FS_ENTRY exists and is a valid path, and when I try to read the files in the directory, it is able to create a not-null FS_ENTRY for all objects in the directory. The problem is that the path for each of these FS_ENTRY objects is "C:\...\lib\" and al_fs_entry_exists() returns false for all of them.
I'm compiling this program on Windows 10. I'm not sure if this is an issue with my code or with Allegro -- has anyone else had an issue similar to this, or can at least offer advice?
How are you creating your original ALLEGRO_FS_ENTRY? Are you using al_create_fs_entry with a relative or absolute path? It seems to work with relative paths on my system. What is the full directory path to your lib folder? Perhaps there is a limitation on the number of characters in the path.
list.exe (statically linked directory listing program)
(Use with a directory as argument or with no argument the current directory is used).
I had this old test program lying around and I ran it on my Windows 10 machine after rebuilding it with MinGW 5.3.0-2 and Allegro 22.214.171.124 and it seems to list directory contents just fine. Give it a try and see if it works for you. If so, maybe there is some code difference? Are you compiling with MinGW or MSVC? Or Clang or Borland maybe?
Hmm... list.exe seems to work fine, but when I compiled FSentry.cpp with a full directory path of "C:\Programs\test" it produced the same result as before. So I suppose it's not an issue with code, but an issue with the way my machine is compiling it?
My compiler is MinGW 5.3.0, with Allegro 5.0.10 (my version came bundled with MinGW 4.7.0), and I'm statically linking to the Allegro library in Code::Blocks. Do you upgrading to 126.96.36.199 would fix the problem, or do you think the issue is something else?
Thread #616495. Printed from Allegro.cc
It's probably a library version problem. Also, you shouldn't mix binaries of Allegro for MinGW 4.7 with MinGW 5.3. The version of MinGW used needs to match.
Yes, you should upgrade. 5.0.10 is pretty old. I have binaries for MinGW 5.3.0-2 and Allegro 188.8.131.52 here :