Sigh, this took longer than expected to finish, and then testing ran into problems which I _think_ is a current ITS and not mine, but... maybe I should just apply the filename-specific part of my ldif patches, after a bit of cleanup.
Or maybe it's better to wait till next release after all, since this gets rather late before the current release.
I forgot, how do I _test_ if the program is running on a box where \ is a directory separator? defined(_WIN32) apparently means the Windows API, not Unix emulations. Or not all of them anyway. Googling around, the best I found was to collect various symbols in an #ifdef - the more the merrier.
Probably belongs in portable.hin, but I don't want to put something I can't even test in such an official place. So left to myself I'm inclined to put something like this in back-ldif in the hope of catching current and future ports, and leave cleanup to someone who uses windows:
#if defined(_WIN32) || defined(_MSC_VER) || /* Native windows. Others? */ \ defined(__MINGW32__) || defined(__CYGWIN__) /* Emulations */ || \ defined( __MSDOS__) || defined( __DJGPP__) || defined(__GO32__) /*:-)*/ # define LDAP_WINDOWS_FILENAMES 1 #endif
Another point, one strangeness I'm wondering about:
back-ldif can b3 compiled to transate {} in DNs to other characters in filenames, e.g. "cn={3}foo" => "cn=<3>foo" or => "cn=!3!foo".
If I remember correctly the point was that '{' and '}' might be special characters in the filesystem. However it doesn't translate all {}'s, it translates the first '{' it encounters, then the next '}', then '{', etc. So cn=foo{{bar}} becomes e.g. cn=foo<{bar>}.
Is there a reason for this? I'm inclined to instead translate every '{' and every '}'. It's not that { and } in DNs from slapd can be configured to be the same character; IX_DNL and IX_DNR are defined unconditionally.