Filesystem routines

Hello everyone,

I’ve been using SDL now for several projects and so far I’m very happy
with it, so I wish to thank the authors for doing such a great job.

I have one issue with SDL, or should I say more of a `new feature’ wish,
that I’ve been thinking about for a while. I must apologise if this has
been discussed before, however I’ve just signed up to this list, and
haven’t had time to search the archives yet.

What I would like to see is a group of functions such as the following:

SDL_FIND_FILE* SDL_FindFirst(char* path, char* filter);
int SDL_FindNext(SDL_FIND_FILE* filerec);
void SDL_FindClose(SDL_FIND_FILE* filerec);

The purpose of which is to iterate through a list of files in a
specified directory. We already have standard functions in the various C
libraries to read and write files, however there is no real portable way
to search for files. The functions that I’ve described correspond very
closely to the Win32 way of iterating through files; from my experience
this is a very simple and clean way to do it, although there may be far
more efficient ways to do it. The POSIX way of opendir(), readdir() and
stat() is not that great, IMHO.

Here is a snippet of C code using the above functions that searches a
directory for a list of text files, to give an example of how they could
be used:

SDL_FIND_FILE* f = SDL_FindFirst("./data/", ".txt");
if (!f) return;
int found = 1;
while (found) {
if (SDL_IS_DIRECTORY(f)) { /
file is a directory / };
AddFileToList(f->name);
/
etc … */
found = SDL_FindNext(f);
}
SDL_FindClose(filerec);

Why would you want this? Well, I’m thinking to use these in a setup such
as how Quake does things, where data files from later archives in an
alphabetically sorted list of archives override data files in earlier
archives (e.g. data files in ZZZ.pak override those in AAA.pak).
Currently there is no easy/portable way to search a given directory for
a list of files such as `*.pak’.

Problems with this? Of course. So far I’ve worked on Win32 and several
UNIX’es and the way they represent the filesystem is totally different,
to say nothing of the other platforms that SDL runs on. I would say that
these functions should take the easy route and pass on the path that
they are given to the underlying platform’s `find file’ functions,
perhaps only converting directory delimiters (e.g. from ‘/’ to ‘’,
etc). Leave the problem of portablly representing paths to the user of
the functions; the only viable way to do it would be to use relative
paths, or perhaps load a base path from a config file.

While I’m on the topic of file-related routines, I’ll also put forward
an idea for some additional functions, the purpose of which would be to
facilitate directory and file manipulation:

char* SDL_GetWorkingDirectory();
char* SDL_GetHomeDirectory(); // “~”, “C:\Documents and Settings\User\
My Documents”, etc
int SDL_ChangeWorkingDirectory(char* newcwd);
int SDL_CreateDirectory(char* dir);
int SDL_DeletePath(char* dir); // Used for files & dirs
int SDL_RenamePath(char* old, char* new); // Used for files & dirs

These are just rough ideas however, I’m primarily interested in the file
search routines. I would greatly appreciate feedback on all of this, as
I’m sure my ideas can be improved upon.

Thanks and Regards,
Stuart Bing?

You could use the excellent PhysicsFS library by Ryan C. Gordon which
does exactly what you need…

It can be found at:
http://www.icculus.org/physfs/

Hope it helps,
Gaetan.On Tue, 2003-11-11 at 09:37, Stuart Bing? wrote:

Hello everyone,

I’ve been using SDL now for several projects and so far I’m very happy
with it, so I wish to thank the authors for doing such a great job.

I have one issue with SDL, or should I say more of a `new feature’ wish,
that I’ve been thinking about for a while. I must apologise if this has
been discussed before, however I’ve just signed up to this list, and
haven’t had time to search the archives yet.

What I would like to see is a group of functions such as the following:

SDL_FIND_FILE* SDL_FindFirst(char* path, char* filter);
int SDL_FindNext(SDL_FIND_FILE* filerec);
void SDL_FindClose(SDL_FIND_FILE* filerec);

The purpose of which is to iterate through a list of files in a
specified directory. We already have standard functions in the various C
libraries to read and write files, however there is no real portable way
to search for files. The functions that I’ve described correspond very
closely to the Win32 way of iterating through files; from my experience
this is a very simple and clean way to do it, although there may be far
more efficient ways to do it. The POSIX way of opendir(), readdir() and
stat() is not that great, IMHO.

Here is a snippet of C code using the above functions that searches a
directory for a list of text files, to give an example of how they could
be used:

SDL_FIND_FILE* f = SDL_FindFirst("./data/", ".txt");
if (!f) return;
int found = 1;
while (found) {
if (SDL_IS_DIRECTORY(f)) { /
file is a directory / };
AddFileToList(f->name);
/
etc … */
found = SDL_FindNext(f);
}
SDL_FindClose(filerec);

Why would you want this? Well, I’m thinking to use these in a setup such
as how Quake does things, where data files from later archives in an
alphabetically sorted list of archives override data files in earlier
archives (e.g. data files in ZZZ.pak override those in AAA.pak).
Currently there is no easy/portable way to search a given directory for
a list of files such as `*.pak’.

Problems with this? Of course. So far I’ve worked on Win32 and several
UNIX’es and the way they represent the filesystem is totally different,
to say nothing of the other platforms that SDL runs on. I would say that
these functions should take the easy route and pass on the path that
they are given to the underlying platform’s `find file’ functions,
perhaps only converting directory delimiters (e.g. from ‘/’ to ‘’,
etc). Leave the problem of portablly representing paths to the user of
the functions; the only viable way to do it would be to use relative
paths, or perhaps load a base path from a config file.

While I’m on the topic of file-related routines, I’ll also put forward
an idea for some additional functions, the purpose of which would be to
facilitate directory and file manipulation:

char* SDL_GetWorkingDirectory();
char* SDL_GetHomeDirectory(); // “~”, “C:\Documents and Settings\User\
My Documents”, etc
int SDL_ChangeWorkingDirectory(char* newcwd);
int SDL_CreateDirectory(char* dir);
int SDL_DeletePath(char* dir); // Used for files & dirs
int SDL_RenamePath(char* old, char* new); // Used for files & dirs

These are just rough ideas however, I’m primarily interested in the file
search routines. I would greatly appreciate feedback on all of this, as
I’m sure my ideas can be improved upon.

Thanks and Regards,
Stuart Bing?


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

May be we could use PhysicsFS, but I have to agree with Stuart that just
adding thos functions for file management (the basic ones, just to
manage paths, files, directories, etc.) will be of great help. Since, if
SDL handles threads, input, etc. Why not handle filesystem? So you only
need a single library and not two.
In my applications all the code is nice except for the file-system code
where you have to use #ifdef _WIN32, etc.

Gaetan de Menten wrote:>You could use the excellent PhysicsFS library by Ryan C. Gordon which

does exactly what you need…

It can be found at:
http://www.icculus.org/physfs/

Hope it helps,
Gaetan.

On Tue, 2003-11-11 at 09:37, Stuart Bing? wrote:

Thanks for the link, I hadn’t come across this library yet.

This library isn’t what I am looking for, however; it is too high level.
I have an existing data loading scheme - the only missing portion is a
cross-platform way of searching for files. The functions that I proposed
can be used as a starting point to build a system similar to PhysicsFS,
however you will also be able to do much more if you have access to the
underlying functions.

As SDL is a multimedia library I believe it should not handle tasks such
as the PAK file example I gave, nor the multitude of functions that
PhysicsFS provides - these items are better left to other libraries. I
do believe, however, that SDL should provide a means of locating a
specific file/group of files (I’ll hazard a guess that you’d be
hard-pressed to find a multimedia application that does not use a data
file of some sort), and should do no more than provide the thinest
possible cross-platform layer to the underlying system’s file/directory
manipulation routines.

  • Stuart

Gaetan de Menten wrote:> You could use the excellent PhysicsFS library by Ryan C. Gordon which

does exactly what you need…

It can be found at:
http://www.icculus.org/physfs/

Stuart Bing? wrote:

What I would like to see is a group of functions such as the following:

SDL_FIND_FILE* SDL_FindFirst(char* path, char* filter);
int SDL_FindNext(SDL_FIND_FILE* filerec);
void SDL_FindClose(SDL_FIND_FILE* filerec);

I wouldn’t like it. The SDL should be as it is. Simple and easy. Not all
games need stuff like this. If it is to be added to SDL, it should go to
some external library. In fact, you can create one yourself :slight_smile:

The purpose of which is to iterate through a list of files in a
specified directory. We already have standard functions in the various C
libraries to read and write files, however there is no real portable way
to search for files. The functions that I’ve described correspond very
closely to the Win32 way of iterating through files; from my experience
this is a very simple and clean way to do it, although there may be far
more efficient ways to do it. The POSIX way of opendir(), readdir() and
stat() is not that great, IMHO.

Well, it’s not great, you’re right, but it’s still easy to work with.
Besides, opendir, readdir, etc. work also on win32, so that is a
portable way of doing things. Just parse the direntry and see if the
extension matches… I did this in my game Njam, it’s really only a few
more lines of code comparing to what you suggest.

Why would you want this? Well, I’m thinking to use these in a setup such
as how Quake does things, where data files from later archives in an
alphabetically sorted list of archives override data files in earlier
archives (e.g. data files in ZZZ.pak override those in AAA.pak).
Currently there is no easy/portable way to search a given directory for
a list of files such as `*.pak’.

The reasons are understood. However, there is a portable way with
opendir/readdir/closedir. Not very nice&easy, but works on most
platforms (Linux, Win32, *BSD, BeOS for sure, others probably).

Problems with this? Of course. So far I’ve worked on Win32 and several
UNIX’es and the way they represent the filesystem is totally different,

Not really. Besides, SDL already converts / to \ on windows.

etc). Leave the problem of portablly representing paths to the user of
the functions; the only viable way to do it would be to use relative
paths, or perhaps load a base path from a config file.

I thought the same before. But some of the distros had to change my
sources to insert full paths. For example, if you run executable on
Linux wiht full path (ex. /usr/local/games/sdl/njam/njam) it doesn’t
change the CWD, so relative paths dont work. So I did something else,
when the game runs, I get directory with argv[0], and chdir to it.

char* SDL_GetWorkingDirectory();

Ok. Good idea.

char* SDL_GetHomeDirectory(); // “~”, “C:\Documents and Settings\User\
My Documents”, etc

How is this portable to Windows98?

int SDL_ChangeWorkingDirectory(char* newcwd);
int SDL_CreateDirectory(char* dir);
int SDL_DeletePath(char* dir); // Used for files & dirs
int SDL_RenamePath(char* old, char* new); // Used for files & dirs

These are just rough ideas however, I’m primarily interested in the file
search routines. I would greatly appreciate feedback on all of this, as
I’m sure my ideas can be improved upon.

The best is to create your own library named: SDL_FileUtils
Make it OpenSource so others can contribute versions for their
platforms, and that others can add to it. For example, you just make
search routines and publish it, others can join and add other usefull
stuff. I’m sure it will be usable, I’m even willing to help you
depending on my free time.–
Milan Babuskov
http://fbexport.sourceforge.net

i like the idea. i don’t think the VC environment has the opendir/readdir
functions… correct me if i’m wrong. please. i’d love to use them.

if this was put into a seperate library, then i’d go one step further and
add access to the native file selector into mix. not sure what to do with
systems that don’t provide hooks for a standard file selector box…

-miles vignol

Miles Vignol wrote:

i like the idea. i don’t think the VC environment has the opendir/readdir
functions… correct me if i’m wrong. please. i’d love to use them.

I don’t know. I use Borland and GCC on Win32.

For Borland, the include file is

#include <dirent.h>

See if you have it. Or just search your “include” directory for opendir(

if this was put into a seperate library, then i’d go one step further and
add access to the native file selector into mix. not sure what to do with
systems that don’t provide hooks for a standard file selector box…

Prehaps you should take a look at wxWindows (www.wxwindows.org). They
emulate file selectors on platforms that don’t support it. Works nice.

HTH–
Milan Babuskov
http://njam.sourceforge.net

VC doesn’t have those functions, but there is an free emulation .h/.lib
floating around the net that works alright. Googling for a few minutes
should turn it up.On Tue, 2003-11-11 at 15:14, Milan Babuskov wrote:

Miles Vignol wrote:

i like the idea. i don’t think the VC environment has the opendir/readdir
functions… correct me if i’m wrong. please. i’d love to use them.

I don’t know. I use Borland and GCC on Win32.

For Borland, the include file is

#include <dirent.h>

See if you have it. Or just search your “include” directory for opendir(

if this was put into a seperate library, then i’d go one step further and
add access to the native file selector into mix. not sure what to do with
systems that don’t provide hooks for a standard file selector box…

Prehaps you should take a look at wxWindows (www.wxwindows.org). They
emulate file selectors on platforms that don’t support it. Works nice.

HTH


Jimmy <@Jimmy>
Jimmy’s World.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20031111/160cfcc9/attachment.pgp

I’m not sure if it’s been mentioned… but

http://www.boost.org/

They have a library, I’m pretty sure is called filesystem… it’s very
cross platform.

  • Andrew> ----- Original Message -----

From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org] On Behalf Of
Milan Babuskov
Sent: Tuesday, November 11, 2003 3:15 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Filesystem routines

Miles Vignol wrote:

i like the idea. i don’t think the VC environment has the
opendir/readdir
functions… correct me if i’m wrong. please. i’d love to use them.

I don’t know. I use Borland and GCC on Win32.

For Borland, the include file is

#include <dirent.h>

See if you have it. Or just search your “include” directory for opendir(

if this was put into a seperate library, then i’d go one step further
and
add access to the native file selector into mix. not sure what to do
with
systems that don’t provide hooks for a standard file selector box…

Prehaps you should take a look at wxWindows (www.wxwindows.org). They
emulate file selectors on platforms that don’t support it. Works nice.

HTH


Milan Babuskov
http://njam.sourceforge.net