- Online Community Forums » Programming Questions » File system routines - al_get_path_tail() returning wrong path component

This thread is locked; no one can reply to it. rss feed Print
File system routines - al_get_path_tail() returning wrong path component
Member #8,518
April 2007

EDIT: Solved!

Years back I made a function that check for which mods are available in subfolders under a subfolder called "Mods" in my game's project directory. When finding a mod the name is stored and used for loading different assets.
However now some of the file system routines that previously worked fine are no longer doing the same thing. I don't know if it is a combination of Windows 10 + Allegro 5.0 or something else.
Anyone else know if new versions of Allegro have had changes made to adapt to file system changes in newer versions of Windows?

Here's a simplified code snippet of what I am doing and the results I get:

1ALLEGRO_PATH *ap; 2char *projectPath; 3char *projectName; 4... 5while(true) 6{ 7 ap = createAnAllegroPathToEachSubfolderUnderTheModsFolder(); 8 ... 9 sprintf(modPath, "%s\\file.txt", al_path_cstr(ap, ALLEGRO_NATIVE_PATH_SEP)); 10 ...

projectPath will contain the correct full path "C:\\Projects\\MyProject\\Mods\\Zelda\\file.txt".

However when using al_get_path_tail() I do not get the last component in the path but the second to last:

10 ... 11 sprintf(projectName, al_get_path_tail(ap)); 12 ... 13}

projectName will contain "Mods" instead of "Zelda".

Same result will happen when using al_get_path_component() with -1 (first from right) as component id:

10 ... 11 sprintf(projectName, al_get_path_component(ap, -1)); 12 ... 13}

projectName will again contain "Mods" instead of "Zelda".

It's like the last component of the path is ignored but back in 2003 when I used the code it worked. The only thing I can think of that has changed is my Windows version.

Trying to find a newer version of Allegro (5.2.5) to try that but no luck finding binaries of this (yet).


EDIT: I just noticed that my ALLEGRO_PATH *get_next_subdirectory_in_directory() function used:
return al_create_path((char*)al_get_fs_entry_name(file));
Instead of:
return al_create_path_for_directory((char*)al_get_fs_entry_name(file));

So a bug due to me. However I don't think I've touched this code since 2013...aaand I think it worked back then. But who remembers. Oh well, problem solved!

Go to: