\brief List all files and directories in the given directory
\param directory The directory to list.
\param list The list that contains the directory entries.
\return -1 on error, otherwise the amount of entries in the list.
*/
extern DECLSPEC int SDLCALL SDL_ListDirectory(const char *directory,
char **list);
Asking because I’ve almost always implemented something like this when
starting something new.
Attached is a small example patch that is neither complete nor tested at
all and stuffed with some TODOs
If something like this would be useful (and I’m not talking about an
extension lib, but SDL itself) I would finish all that stuff with
pleasure and submit a patch to the tracker.
I’ve also implemented this for android (jni and AssetManager::list)
I think that at least one like that is needed to support automatic
recursive assets (or other stuff) at a capable level, this matter doesn’t
need to be super featured, but at least, provide a mibimum :-).
Perhaps, owners think if they start this they would inject all of PhysFS,
zip, rights, etcetera. But neither that happens, nor there is a minimal
sufficient interface ;-).
indeed, it is not the intention to get more file system stuff into it.
but i honestly think that this is worth a small api - it e.g. can also
be implemented in nacl, emscripten and so on - but i don’t think that
this is the scope of e.g. phsfs - but it is (or can be) the scope of sdl imo.Am 05.07.2014 16:19, schrieb Juan Manuel Borges Ca?o:
I think that at least one like that is needed to support automatic
recursive assets (or other stuff) at a capable level, this matter
doesn’t need to be super featured, but at least, provide a mibimum :-).
Perhaps, owners think if they start this they would inject all of
PhysFS, zip, rights, etcetera. But neither that happens, nor there is
a minimal sufficient interface ;-).
PhysicsFS doesn’t even have a proper way to list directories except
from mounted archives so that still wouldn’t clash with SDL doing it
(there’s a way to cheat around that, but it’s pretty much that, a
massive hack, even if it works flawlessly).
For whatever it’s worth to you, this topic has been briefly discussed before, with good points made on both sides – Feature request: SDL_file_exists, SDL_mkdir [1].
I think it would be a nice function to have without a doubt. I also believe that recently introduced functions like SDL_GetPrefPath are possibly hints that a basic filesystem API is an acceptable scope for inclusion into SDL, or more like (IMO), an optional extension, like how SDL_image and SDL_ttf.
I personally think it is worthwhile for SDL to gain this level of functionality perhaps with some security-conscious limitations. I don’t think PhysFS should have more ability than it has now as PhysFS’s limits are to sandbox potentially untrusted scripts.
This function in SDL might have a few simple flags associated: return files, return directories, return both, and whether SDL should take the time to sort (or ask the OS to sort) the results.
I think the rules that make sense are that . and … are never included, and anything special (symlinks, devices, etc) aren’t either. Though if given a symlinks to read, that can be dereferenced.
JosephSent via mobile
On Jul 5, 2014, at 11:09, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
PhysicsFS doesn’t even have a proper way to list directories except
from mounted archives so that still wouldn’t clash with SDL doing it
(there’s a way to cheat around that, but it’s pretty much that, a
massive hack, even if it works flawlessly).
How would you handle symbolic links in Windows XP? (SDL still supports XP, aye?)
I know relatively little about Windows per se, but a quick search seems to imply that XP only supports the creation of hard links for files and directories. Apparently, only Vista and beyond support the concept of symbolic links. I suppose “better late than never!” applies here ;D (it only took MS ~25…30 years to get around to it…)
Cheers,
Jeffrey Carpenter
<@Jeffrey_Carpenter>On 2014/07/ 05, at 23:12, T. Joseph Carter wrote:
I think the rules that make sense are that . and … are never included, and anything special (symlinks, devices, etc) aren’t either. Though if given a symlinks to read, that can be dereferenced.
You don’t. XP basically doesn’t support them. Which is fine
because, as I said, the function should only return files and/or
directories. The only time a symlink should be followed is if the OS
supports it and it is provided by the user as the path to read files
out of. (It tends to happen in development environments often,
installations only in the event of something like a one-of-many
source engines accessing a common data store.
Generally symlinks should be considered a no-no for security reasons
all together, but real-world practicality has frequently required
them to be an option. Example: Modern open source ports of games
written for single-user systems like DOS or Win9x.
These tended to be one port of many (HOW many Doom and Quake ports
were there?), and the original engines were not (and were not
designed to be) multi-user aware. They (usually) wanted one single
read-write directory to be the root of all they did. And so they
were usually handled thusly:
Some script/tool would extract the commercial game data and
basedir from something resembling install media or an installed copy
from an inferior OS. It’d put the data someplace common and
port-agnostic following whatever standards the distribution uses.
FHS probably dictates these things belong in /opt somewhere, but in
my experience it usually wound up in /usr/share because rmfzuzza???
[mumbles incoherently]
The source port would then have ITS basedir located in ${sharedir}
because it would (or at least could) have files added to support
shiny new features that were either incompatible with or at least
unsupported by everyone else. The commercial content would be
symlinked in, and of course all of this is read-only.
The source port would be modified to use a shadow root in the
user’s home directory. All writes happen there, and it’d be searched
first for reads.
That kind of organization isn’t generally possible on XP or even more
modern Windows systems and it becomes up to the user to set it up in
an intelligent way. The shadow basedin the user’s directory tends to
get used, but that’s outside SDL’s scope. If the read-write
directory is not guessable, that further reduces the possible
exploits. But that too is outside of SDL’s scope. Just make sure
your read/write directory is something unguessable and you’re on the
right path.
On 2014/07/ 05, at 23:12, T. Joseph Carter <@T_Joseph_Carter> wrote:
I think the rules that make sense are that . and … are never included, and anything special (symlinks, devices, etc) aren’t either. Though if given a symlinks to read, that can be dereferenced.
How would you handle symbolic links in Windows XP? (SDL still supports XP, aye?)
I know relatively little about Windows per se, but a quick search seems to imply that XP only supports the creation of hard links for files and directories. Apparently, only Vista and beyond support the concept of symbolic links. I suppose “better late than never!” applies here ;D (it only took MS ~25…30 years to get around to it…)
For those of us who don’t use it, could you summarize what you mean
here? A quick search for a brief summary of Boost’s handling of
symlinks didn’t return one.
JosephOn Wed, Jul 09, 2014 at 01:52:18AM +0200, Robotic-Brain wrote:
If this gets implemented, I think it should behave similar to boost
filesystem in terms of symlinks etc.
boost::filesystem basically is a path manipulation API
you give it a POSIX path and it translates it internally to a native
path which you can later use to fopen a file. (Or use those crazy
streams)
Additionally it has some query functions like exists(), is_directory(),
is_regular_file() and is_symlink().
Only those actually interact with the underlying filesystem
I think this design is great since you can simply construct your path
with . and … don’t bother with the actual location of the file. (use
path.absolute() for sanity checking to limit security risks)
Using user defined paths is also trivial since you can give it native
paths, which the user understands, or POSIX paths, which are platform
agnostic.
The only thing missing is querying common locations like
/home// or MyDocuments etc.On 09.07.2014 06:10, T. Joseph Carter wrote:
For those of us who don’t use it, could you summarize what you mean
here? A quick search for a brief summary of Boost’s handling of
symlinks didn’t return one.
Joseph
On Wed, Jul 09, 2014 at 01:52:18AM +0200, Robotic-Brain wrote:
If this gets implemented, I think it should behave similar to boost
filesystem in terms of symlinks etc.
addendum: Somewhere I saw a code snippet to retrieve the “Bundle Path”
(On OSX: /Applications/<App_name>.app/Contents/Resources/
On Win: C:\path\to\exe\Resources)
has this been implemented in SDL since?
If not, this would be really useful to locate assetsOn 09.07.2014 06:38, Robotic-Brain wrote:
TLDR: it follows symlinks by default
boost::filesystem basically is a path manipulation API
you give it a POSIX path and it translates it internally to a native
path which you can later use to fopen a file. (Or use those crazy
streams)
Additionally it has some query functions like exists(),
is_directory(), is_regular_file() and is_symlink().
Only those actually interact with the underlying filesystem
I think this design is great since you can simply construct your path
with . and … don’t bother with the actual location of the file. (use
path.absolute() for sanity checking to limit security risks)
Using user defined paths is also trivial since you can give it native
paths, which the user understands, or POSIX paths, which are platform
agnostic.
The only thing missing is querying common locations like
/home// or MyDocuments etc.
On 09.07.2014 06:10, T. Joseph Carter wrote:
For those of us who don’t use it, could you summarize what you mean
here? A quick search for a brief summary of Boost’s handling of
symlinks didn’t return one.
Joseph
On Wed, Jul 09, 2014 at 01:52:18AM +0200, Robotic-Brain wrote:
If this gets implemented, I think it should behave similar to boost
filesystem in terms of symlinks etc.
I think SDL_GetBasePath can do (roughly) what you want.On Jul 9, 2014, at 1:45 AM, Robotic-Brain wrote:
addendum: Somewhere I saw a code snippet to retrieve the “Bundle Path”
(On OSX: /Applications/<App_name>.app/Contents/Resources/
On Win: C:\path\to\exe\Resources)
has this been implemented in SDL since?
If not, this would be really useful to locate assets
Yes that’s exactly it
the snippet was a workaround for SDL 1.xAm 09.07.2014 06:48, schrieb Alex Szpakowski:
I think SDL_GetBasePath can do (roughly) what you want.
On Jul 9, 2014, at 1:45 AM, Robotic-Brain <@Robotic-Brain> wrote:
addendum: Somewhere I saw a code snippet to retrieve the “Bundle Path”
(On OSX: /Applications/<App_name>.app/Contents/Resources/
On Win: C:\path\to\exe\Resources)
has this been implemented in SDL since?
If not, this would be really useful to locate assets
It’d put the data someplace common and