The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi.

Could a function like this be useful for SDL?

/**
* \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)

What do you guys think?

Regards
Martin

--

http://www.caveproductions.org/
https://www.facebook.com/caveexpress
https://twitter.com/MartinGerhardy


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 .

Am 05.07.2014 16:19, schrieb Juan Manuel Borges Caño:

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.

--

http://www.caveproductions.org/
https://www.facebook.com/caveexpress
https://twitter.com/MartinGerhardy

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

1. https://forums.libsdl.org/viewtopic.php?t=10051&highlight=sdlfileexists

Cheers,
Jeffrey Carpenter


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

Joseph
Sent via mobile

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 2014/07/ 05, at 23:12, T. Joseph Carter wrote:

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



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2014-07-06 1:37 GMT-03:00, Jeffrey Carpenter:

Huh, you wouldn't? If the operating system doesn't support them then
you would never have to bother in the first place.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sat, Jul 05, 2014 at 11:37:53PM -0500, Jeffrey Carpenter wrote:

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:

1. 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]

2. 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.

3. 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.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If this gets implemented, I think it should behave similar to boost
filesystem in terms of symlinks etc.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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/<username>/ or MyDocuments etc.

On 09.07.2014 06:10, T. Joseph Carter wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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


On 09.07.2014 06:38, Robotic-Brain wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think SDL_GetBasePath can do (roughly) what you want.

On Jul 9, 2014, at 1:45 AM, Robotic-Brain wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes that's exactly it
the snippet was a workaround for SDL 1.x


Am 09.07.2014 06:48, schrieb Alex Szpakowski:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org