[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: non-unix help needed: valid filename characters?
Hallvard B Furuseth wrote:
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.
A current back-ldif ITS? Or something else?
Or maybe it's better to wait till next release after all, since this
gets rather late before the current release.
I guess just commit to HEAD in stages. We can skip this for 2.4.9 if necessary.
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.
ldap_config.h just tests for _WIN32 and defines LDAP_DIRSEP. There is no
reason to do anything beyond that. Cygwin does its own machinations already
and we don't know or care what they are.
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
Ugh. No.
I'm sure slapd can't be compiled on MSDOS or DJGPP any more anyway. libldap
probably still works for them, but that's beyond the scope of back-ldif.
Another point, one strangeness I'm wondering about:
back-ldif can be 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.
Seems like it should translate all, yes.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/