[core] Refactor ecal_path_processing.cpp to C++17 std::filesystem

[Peguen]

Description

Replaces the custom EcalUtils::Filesystem / EcalUtils::String wrappers in ecal_path_processing.cpp with standard C++17 <filesystem> equivalents and fixes several bugs found during the review.

[hannemn]

@FlorianReimold Can you give the PR a short review please? Thanks. :-)

[FlorianReimold]

This is my first review. I will perform another review regarding Unicode correctness. Please stay tuned 😉

[FlorianReimold]

I feel like exceptions should be caught or the error_code should be passed, so that a failure while removing the dummy test file does not crash the application.

[FlorianReimold]

Using hardcoded ANSI functions it probably is fine in 99.9% of all cases, as the tmp dir will most likely only consist of 7-bit ASCII characters anyways. However, it it doesn't, this will fail, as the ANSI output is later interpreted as UTF-8 (I think).
Thus, the proper way would be to use the hardcoded Unicode equivalent and convert that to UTF-8.

I found hardcoded ANSI functions in the following functions:

getTempDir

• GetTempPathA

DirProvider::uniqueTmpDir

• GetTempFileNameA
• DeleteFileA
• CreateDirectoryA

[FlorianReimold]

Ok, so I did a small test and come to the conclusion that the current implementation does not handle Unicode paths in Windows.

Take the following code for example:

ecal/ecal/core/src/config/ecal_path_processing.cpp

Lines 356 to 360 in 92f9973

	std::string checkForValidConfigFilePath(const std::string& config_file_, const Util::DirProvider& dir_provider_ /* = Util::DirProvider() */, const Util::DirManager& dir_manager_ /* = Util::DirManager() */)
	{
	std::error_code ec;
	const std::string cwd_directory_path = std::filesystem::current_path(ec).string();

When any eCAL App is being started from a path with unicode characters that don't appear in the currently configure codepage (in my test D:\testdir\Beer🍺), the current working directory cannot be represented with 8 bit characters (Which would be ANSI on Windows so depending on the Codepage! But those legacy codepages don't have emojies.) and therefore .string() throws an exception internally and returns an empty string.
The solution for this problem is to call .wstring() on windows to get the UTF-16 path as a string and convert it to UTF-8 for passing it through the code.

Therefore, a deeper analysis has to be done to replace all non-widestring calls with widestring equivalents on windows.

[FlorianReimold]

I conducted a manual review of the PR changes and didn't find any issues. I think, it should now handle Unicode data properly. I will however continue with a small review of the non-changed codebase as well so see if the surrounding code handles it properly.

[FlorianReimold]

OK, looks good for me. Widestring and UTF 8 was used consistently everywhere I checked. An AI review told me the same. The AI review mentioned that we are currently not supporting long file paths for the temp directory (it uses MAX_PATH) and that there are ways to also support long paths there. But I think the current state is fine.