Re: non-unix help needed: valid filename characters?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Hallvard