extract_path_parts bug in windows while data is not on the c-drive

[MaxvandenBoom]

The function 'extract_path_parts' in meflib.c has a bug, which in Windows stops all read functions from working when the MEF3 data is not on the c-drive. It looks like a copy-paste from the LINUX original (before the #ifdef _WIN32 was introduced). In the linux part a check is performed to see wheter the path starts from root (first character is '/'). However, this does not translate to windows by just checking whether the first character is a 'c', that excludes the ability to have data on other drives. A possible solution would be to check if the second character is a colon character.

Even if you would correct this detection, then there would be another bug since the function getenv("PWD") is called. In windows (or atleast in Windows 7), the call getenv("PWD") returns a text like '(null)\'. As a result, it creates an invalid filepath (e.g. '(null)\D:\testData\') and crashes the program later due to null references.

My (maybe not very elegant) solution is to ignore this root check for windows altogether and keep only: MEF_strncpy(temp_full_file_name, full_file_name, MEF_FULL_FILE_NAME_BYTES);

This bug applies to both meflib and pymef (since it builds on that), the multiplatform branch. Hope this helps

[cimbi]

Right, silly me. I did not realize that the "root" path does not actually make sense on windows

[cimbi]

Resolved by #10