SDL_ListDirectory |
Martin Gerhardy
Guest
|
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 |
|||||||||||
|
SDL_ListDirectory |
SDL_ListDirectory |
Martin Gerhardy
Guest
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Sik
|
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 |
|||||||||||
|
SDL_ListDirectory |
Jeffrey Carpenter
Guest
|
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 |
|||||||||||
|
SDL_ListDirectory |
Joseph Carter
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Jeffrey Carpenter
Guest
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Sik
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Joseph Carter
|
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 |
|||||||||||||||
|
SDL_ListDirectory |
Robotic-Brain
Guest
|
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 |
|||||||||||
|
SDL_ListDirectory |
Joseph Carter
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Robotic-Brain
Guest
|
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 |
|||||||||||||||
|
SDL_ListDirectory |
Robotic-Brain
Guest
|
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 |
|||||||||||||||||
|
SDL_ListDirectory |
Alex Szpakowski
Guest
|
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 |
|||||||||||||
|
SDL_ListDirectory |
Robotic-Brain
Guest
|
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 |
|||||||||||||||
|