Paths::loadCustomConfiguration lookup of folder paths steps up one level too much

[GB609]

Concerned project

Standalone emulationstation

Distribution Version

Current master commit

Architecture

Arch Linux

Issue description

The method Paths::loadCustomConfiguration(false) tries to resolve several directories needed by emulationstation relative to the file emulationstation.ini, assuming that the directory containing this file is owned by emulationstation.
The directory containing this file is saved as variable named 'relativeTo', which is then used as the basis to find other directories. However, these lookups don't use 'relativeTo' directory, but step up one more level, see:

std::string path = mEmulationStationPath + std::string("/") + SETTINGS_FILENAME;
if (!Utils::FileSystem::exists(path))
  path = mUserEmulationStationPath + std::string("/") + SETTINGS_FILENAME;
if (!Utils::FileSystem::exists(path))
  path = Utils::FileSystem::getParent(mUserEmulationStationPath) + std::string("/") + SETTINGS_FILENAME;

if (!Utils::FileSystem::exists(path))
  return;
		
std::string relativeTo = Utils::FileSystem::getParent(path);

if (Utils::String::startsWith(variable, "system."))
{
  auto name = Utils::FileSystem::getGenericPath(variable.substr(7));
  auto dir = Utils::FileSystem::getCanonicalPath(mUserEmulationStationPath + "/" + name);
  if (Utils::FileSystem::isDirectory(dir))
    ret[variable] = dir;
  else
  {
    auto dir = Utils::FileSystem::getCanonicalPath(relativeTo + "/../system/" + name);
    if (Utils::FileSystem::isDirectory(dir))
      ret[variable] = dir;
  }
}
else
{
  auto dir = Utils::FileSystem::getCanonicalPath(relativeTo + "/../" + variable);
  if (Utils::FileSystem::isDirectory(dir))
    ret[variable] = dir;
  else
  {
    auto dir = Utils::FileSystem::getCanonicalPath(relativeTo + "/../system/" + variable);
    if (Utils::FileSystem::isDirectory(dir))
      ret[variable] = dir;
  }
}

When my ini file and the executable are placed e.g. in /opt/emulationstation/, it will attempt to find system resource folders like music, themes, decorations, shaders, videofilters, padtokey as system folders and user overrides under /opt/emulationstation/../system/{foldername}. effectively resulting in all these emulationstation specific folder expected to be under /opt/system which i think is wrong.

When the ini is placed in /home/user/.emulationstation/, the folders are expected to be under /home/user/system, which is wrong again.

There is also fallback where user specific folders are searched, using ../ as addition to relativeTo (with ../system/ as fallback). In that case it's effectively looking for these folders with the path /home/user/{foldername}

It only works partly correct, when i deliberately create a second package-owned subdirectory, e.g /opt/emulationstation/bin, then the resources are expected to be in
/opt/emulationstation/{foldername} or /opt/emulationstation/system/{foldername}, but that setup can't be taken for granted.

I think the ../ has to go completely here in the lookup logic.
Which directory is used as parent does not matter, the same applies if you change /opt to /bin or /usr. Emulationstation does not stay within its own realm/directory when looking for private resources.