platform-independant recursive folder creation

[gerdb]

hi,

i like to create a folder "save/example_001/class_to_test" in one function-call (recursivly)

how do i do that with irrlicht?

EDIT:

when i try to add something like this to irrlicht by writing some static functions to CFileSystem

cpp Code: Select all

 
CFileSystem
{
        // ...
public:
//! Determines if a file exists and can be opened.
        virtual bool existFile(const path& filename) const;
 
        //! Determines if a directory exists and can be opened.
        virtual bool existDirectory(const path& filename) const;
 
        //! creates a file on native FileSystem or a virtual one, depending on FileSystemType
        virtual bool createFile(const path& filename, s32 mode = 0777 );
 
        //! creates a directory on native FileSystem or a virtual one, depending on FileSystemType
        virtual bool createDirectory(const path& filename, s32 mode = 0777 );
 
        //! deletes a file from native FileSystem or a virtual one, depending on FileSystemType
        virtual bool removeFile(const path& filename);
 
        //! deletes a directory from native FileSystem or a virtual one, depending on FileSystemType
        virtual bool removeDirectory(const path& filename);
        // ...
}
 

so that i dont rely on any IrrlichtDevice*, IFileSystem* Pointer,

will that be conform to irrlicht coding rules and maybe accepted for svn-merge?

cpp Code: Select all

 
    // resulting code to create a folder
    // #1 function extracts path from fileName
    // #2 function recursivly creates folders
    io::IFileSystem::mkdir(  "save/example_001/class_to_test/image_000.png" );
 
 

[hybrid]

No, definitely not. First you don't adhere to the camel-case policy of Irrlicht, and second static methods don't make any sense here. As this would mean that you don't need to have a file system yet, which would render these methods quite problematic. Moreover, you have to provide implementations for all platforms and most file systems (where possible), otherwise the file system structure would fragment even more.

[gerdb]

static methods are just functions that are sorted to classes because they relate to their field of application

First you don't adhere to the camel-case policy of Irrlicht

sry, im really dont understand that sentence. what is a camel-case?

As this would mean that you don't need to have a file system yet

yes, i dont need an instance of class IFileSystem, like i dont need an instance of IImage for using IImage::getBitsPerPixelFromFormat().

which would render these methods quite problematic

sry, i dont render(how does this word even make slightly sense) anything when i wish to create a filesystemfolder recursivly.

you have to provide implementations for all platforms and most file systems (where possible)

i know that, thats the definition of platform-independence.
i've done it for Linux and Windows already, for Mac and other i need help, as i dont know their API's
and since it does not anyhow depend on irrlicht, it should be static and sorted to class IFileSystem.

otherwise the file system structure would fragment even more.

under Linux there is no fragmentation, and when, it is as it is wished by the OS
the fragmentation depends on the OS's implementation of their API. and i dont change OS's API. ( so im not the reason of fragmentation )

Pls make a working code with existing irrlicht functionality accomplishing my task. Then i would use it.

that answer was just unmotivating and not helping. Say how it is done right your way, then i would consider, but i didnt get anything to consider about.

strange here

[hybrid]

Sorry, you seem to have several misunderstandings here, due to language problems. Here are the explanations in the same order as before

Static methods don't make sense here. The file systems are very different, so you need to know about which file system you're talking, and you need a reference to this instantiated file system. Irrlicht can have virtual file systems, and to know whether you are working with the native disk file system or something else, you need the object. So no fun with static methods. Even worse, the interface wouldn't be exported this way, as the implementation would have to go to the CFileSystem.cpp, and the IFileSystem.h would require virtual functions which does not work with static ones.

Camel case is the naming style where the first word is lower case and the next words are attached without any delimiter, but with an upper case capital. resultsLookLikeThis. thisIsAlsoAnExample. camelCase so to say.

To render something useless is a nicer wording for 'make it useless'. It does not have anything in common with render capabilities of 3d engines.

As I said above, you don't need just the three or four OS implementations for the native disk file systems, but also for the virtual file systems in the end. Just wanted to note that it's not as easy as looking up the OSX API.

Fragementation is here also not the technical term of hard disk fragmentation. An API can be fragmented if the components and building parts of the API are not properly developed and use different ways to achieve certain objectives. Or functions are only partially supported by the structures of the API. The latter would be especially a problem for Irrlicht, as lack of support of such functions in the virtual file systems would make use of these functions rather limited. Right now, you can use a test environment for your app with the usual file system and later on put all the assets into a zip file and load them from there. If we introduce all these functions without further support in all file systems, the API gets fragmented, as we have to explain for every file system which function is supported etc.

It has nothing to do with demotivation. I just have to make sure that we do not add something which is quickly coded by someone, only covering the easy 20% of the job. And we as the core maintainers have to put a huge effort into this code for the 80% rest. If you, or someone else, will do the initial 80%, we would be happy to put the 20% rest into it. Or even more. But right now my answer to your initial question is simply: No, with only this initial part, the chances are low to be included. BTW: There's already a tracker request for this suggestion, maybe start from there with your ideas.

[gerdb]

can you provide a example that creates a "real" folder with IFileSystem

I currently add some functions to CImage, i like to implement a quick "save" memberfunction that shall automaticly create missing subFolders from provided fileName

I finished most of the functions like scale, rotate, filter,drawLine, drawCircle and like to test them in a example.cpp, therefore i like to create a folder "save/27.example", something like that, but cant create a folder with irrlicht.

http://benjaminhampe.be.ohost.de/IrrlichtForum/EImageFilter.h
http://benjaminhampe.be.ohost.de/IrrlichtForum/IImage.h
http://benjaminhampe.be.ohost.de/IrrlichtForum/CImage.h
http://benjaminhampe.be.ohost.de/IrrlichtForum/CImage.cpp

[CuteAlien]

I don't think we can create folders in Irrlicht currently. So for now you have to use OS functions for that.

[randomMesh]

I'd use Boost::Filesystem

[gerdb]

@randomMesh,

thx, i have no problems in creating directories, but i wish that irrlicht can do that, so we dont need boost for such a simple task, and i can write my CImage example without any additional lib, of course boost has a lot more to offer like regex, that i use very often.

@hybrid

so i forgot about static methods because of precious virtual filesystems, and did your camel-case policy, hope it applies to you.

result:

cpp Code: Select all

 
        //! Determines if a file exists and can be opened.
        virtual bool existFile(const path& filename) const;
 
        //! Determines if a directory exists and can be opened.
        virtual bool existDirectory(const path& filename) const;
 
        //! creates a file on native FileSystem or a virtual one, depending on FileSystemType
        virtual bool createFile(const path& filename, s32 mode = 0777 );
 
        //! creates a directory on native FileSystem or a virtual one, depending on FileSystemType
        virtual bool createDirectory(const path& filename, s32 mode = 0777 );
 
        //! deletes a file from native FileSystem or a virtual one, depending on FileSystemType
        virtual bool removeFile(const path& filename);
 
        //! deletes a directory from native FileSystem or a virtual one, depending on FileSystemType
        virtual bool removeDirectory(const path& filename);
 

my questions are:

is that ok to contribute, im working on implementation with recursive creation/deletion and some filter like "*.*", "filename.*", "*.jpg"?

it will only depend on some standard headers that are likely aready used in irrlicht.

there are many bad chosen fn-names in CFileSystem, i dont know who needs them.

addFolderFileArchive --> createDirectory, makes a much more meaningful name

i took existFile as base of my imps, because of the use of #defines i dont know very good.

the part for virtual filesystems you have to implement yourself or give some advices, i let space and comment the areas where it should be standing.

[hybrid]

existFile, existDirectory and createFile already exist. And of course returning just a bool upon createFile is also odd, as you cannot work with that file in such a way. The latter might be called touchFile instead, updating the access time and creating the file non-opened in case of non-existence. And a very important one: addFolderFileArchive is not creating a directory! It adds a virtual file system from already existing directories and files. And finally naming scheme again: createDirectory is not possible under Irrlicht, as create methods do a grab on the pointer that was returned. Since you return a bool, you have to call it differently, maybe makeDirectory.
BTW. Where are the implementations?

[gerdb]

Hi,

so i've now uploaded my current project, it just depends on irrlicht-1.7.3 headers

i uploaded 2 LogFiles, one for Windows and one for ZorinOS (Ubuntu Linux)

its not anyhow finished yet but should give a overview of what i try to accomplish.

Code:
http://benjaminhampe.be.ohost.de/IrrlichtForum/FileSystem/fs.cpp

Project:
http://benjaminhampe.be.ohost.de/IrrlichtForum/FileSystem/dev.zip

LogFiles:
http://benjaminhampe.be.ohost.de/IrrlichtForum/FileSystem/Windows_Test.log
http://benjaminhampe.be.ohost.de/IrrlichtForum/FileSystem/Posix_Test.log

[gerdb]

some questions:

1. when do i need to _IRR_IMPLEMENT_MANAGED_M..BUGFIX, exactly before the return?
2. does linux has unicode variants for all its system calls or do i always have to convert wide-char to multibyte?
3. do all char* functions support multibyte strings?

guess other questions will follow.

[hybrid]

The managed marshalling bugfix is not necessary anymore, we will remove this code in the future from Irrlicht. So don't bother with it. Otherwise you have to call it immediately before the return statement, but only in case the return value can become 'false' at some point.
We do not support the unicode file systems under Linux. So io::path can be assumed to be char* under Linux. Not sure if you have to do any conversions, or if this will work automatically as is.
Which functions do you mean? But yes, you can probably hit a non-ascii char anywhere.

[gerdb]

thx for the answers,

i did not find any unicode variants for system(), or native API calls like mkdir() for Linux-like (i was first confused by MS Pseudo Posix _wsystem()),

so now i convert them to mbstr using wcstomb() and hope Linux will work without ever complaining about.

I guess it does not hurt to have WCHAR_FILESYSTEM switches taken into account for Linux Implementation, so i keep them, if they are ever needed.

h.a.n.d.