It seems that a `Glib::ConvertError` is thrown, and then the
function that catches the error causes another ConvertError in
`err.what()` (which presumably include the filename that
causes the error).
relevant part of the backtrace (macOS Crashdump):
```
Glib::ConvertError::throw_func(_GError*) + 56
Glib::Error::throw_exception(_GError*) + 292
Glib::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, Glib::ustring const&) + 131
StringPrivate::Composition& StringPrivate::Composition::arg<Glib::ustring>(Glib::ustring const&) + 25
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > string_compose<Glib::ustring> (...) + 81
PBD::run_functor_for_paths(...) + 1313
```
This fixes some edge-cases when scanning recent sessions
in get_state_files_in_directory() and likely some other
places that use run_functor_for_paths in case the folder
contains files with non UTF-8 names.
This fixes the libpbd testCanonicalPathUTF8 and libardour
open_session_utf8_path unit tests
You can now have Sessions with localized names containing characters that
aren't in the system codepage on Windows.
It also fixes the issue where a Session would not open when it was moved into a
path with characters that aren't in the system codepage.
The only use case for calling canonical_path/realpath on the session path
AFAICT is for resolving relative paths that are passed via the command
line/terminal. I'm doubtful that works correctly on Windows because of
character encoding issues with the current API we use for that(not glib), so it
is slightly ironic that this issue was caused by an incorrect implementation of
a function that is not really necessary on Windows at this point in time.
Remove the directory recursively including itself. The function
is used in two places only:
* LV2Plugin::add_state() -- no change, remove tmp. state
* Session::save_as() -- on error, remove target
In both cases removing the folder itself is correct.
The infinite loop would happen if the 2 supplied paths were on different Windows drives - for example if one was on drive C:\ and the other on drive E:\
I don't think this new test will be detrimental to the other platforms but if it is, we could easily separate it out with a '#ifdef PLATFORM_WINDOWS' directive.
This was a very clever attempt to fix a non-problem. If the platform doesn't have enough file descriptors available
then the platform is broken and we're not going to hack around trying to fix it.
Both these functions use the internal function run_functor_for_paths
which takes a Searchpath so this avoids a temporary variable in cases
where a Searchpath is passed directly.
The usage is the same as the compiler will generate a temporary Searchpath
from a string(directory path) if necessary.
