mtasa-blue

mtasa-blue copied to clipboard

Also refactored SharedUtil a little (WIN32 might not be defined. _WIN32 will always be defined)

Syntax: ~~table fileListDir ( string path )~~ table pathListDir ( string path ) returns table of entries on success, nil on failure

Additional functions

~~bool isFile ( string path )~~ bool pathIsFile ( string path ) Returns true if path is a file, false if a directory or path doesn't exist

~~bool isDirectory ( string path )~~ bool pathIsDirectory ( string path ) Returns true if path is a directory, false if a file or path doesn't exist

OOP functions

path.listDir => pathListDir path.isFile => pathIsFile path.isDirectory => pathIsDirectory

---

Related: #346

Is this supposed to return a list of files in a directory?

Is this supposed to return a list of files in a directory?

Relative to a current resource, yes

Is the Unix code block functional with if (!(dir = opendir("c:\\src\\")))? Also, don't you exclude the directory items in the < C++17 block? And last, how can the scripter differentiate between file and directory?

Is the Unix code block functional with if (!(dir = opendir("c:\\src\\")))? Also, don't you exclude the directory items in the < C++17 block? And last, how can the scripter differentiate between file and directory?

1. Changed path to the actual path. Should be functional now
2. Now including all files in a directory without adding the directory name before it too
3. via isFile and isDirectory functions (comment edited)

Wouldn't it make more sense to append a directory separator for directory items? Checking each item whether it's a directory or file seems expensive?

Wouldn't it make more sense to append a directory separator for directory items?

It might cause some issues when messing with directories directly via that function (unless mta takes care of that already)

Checking each item whether it's a directory or file seems expensive?

No, it's not really expensive.

If MTA doesn't have problems with directories ending with \ | / then sure, I can add a separator for directory entries

I don't think fileListDir makes a lot of sense as a name. Perhaps something like getDirectoryEntries or (or, I'd prefer to separate them, getDirectoryFiles and getDirectoryFolders, both with a bool recursive parameter as well. Or, could even go with pathGetFolders, pathGetFiles [if we want to follow the file prefix convention thingy]

I don't think fileListDir makes a lot of sense as a name. Perhaps something like getDirectoryEntries or (or, I'd prefer to separate them, getDirectoryFiles and getDirectoryFolders, both with a bool recursive parameter as well. Or, could even go with pathGetFolders, pathGetFiles [if we want to follow the file prefix convention thingy]

its better to have one function that gets all entries that you can sort by using isFile/isDirectory functions.

There's the module FileSystem which already does the same and has some more features/functions btw. Although could be added nativelly yes if the only purpose is to get files from a directory instead of using the module just for that.

There's the module FileSystem which already does the same and has some more features/functions btw. Although could be added nativelly yes if the only purpose is to get files from a directory instead of using the module just for that.

Using module for that will decrease performance (since you have to load the module, load its functions and events not to mention modules are very limited and you cant use almost any MTA functions there at all without refactoring the whole mta server). Also that would only make the command work in server scripts only.

Implementing it directly in MTA solves all these issues

There's the module FileSystem which already does the same and has some more features/functions btw. Although could be added nativelly yes if the only purpose is to get files from a directory instead of using the module just for that.

Using module for that will decrease performance (since you have to load the module, load its functions and events not to mention modules are very limited and you cant use almost any MTA functions there at all without refactoring the whole mta server). Also that would only make the command work in server scripts only.

Implementing it directly in MTA solves all these issues

Uhm I'm not sure if we really have these issues in the (FileSystem) module. But I do agree that having the functions client-side and being directly implemented into MTA is better.

There's the module FileSystem which already does the same and has some more features/functions btw. Although could be added nativelly yes if the only purpose is to get files from a directory instead of using the module just for that.

Using module for that will decrease performance (since you have to load the module, load its functions and events not to mention modules are very limited and you cant use almost any MTA functions there at all without refactoring the whole mta server). Also that would only make the command work in server scripts only.

Implementing it directly in MTA solves all these issues

I doubt that modules can affect performance in a context of filesystem functions. The main disadvantage that modules have - they don't exist on a client side. So the only way to add proposed in this PR functions is to make them a part of MTA.

But I personally would not say that these functions are really needed on a client side. Typically, server(and therefore client scripts) know which files exist on a client and how to reach them, which makes sense from the security perspective.

There's been many code reviews, so merging. @TracerDS thanks, please add it to wiki though