hyc@symas.com writes:

h.b.furuseth@usit.uio.no wrote:

...

• back-ldif escapes the directory separator as <hex value>. But Windows uses "" as directory separator, so that doesn't help. It needs another escape character.

  To avoid double hex-escaping of DNs that contain "", we can pick another escape char, e.g. "^", escape that too, and translate "" to it. Thus DN "cn=x^y\2Cz" gets filename "cn=x^5Ey^2Cz.ldif".

That sounds fine. Is there any reason not to use %, which is already used for URL encoding?

Good point. The filenames I suggested will not be valid URLs but will resemble them, but that can be fixed by using proper URL-encoding of RDNs. Filenames for RDNs with \ in them get a bit longer though.

...

• More characters should likely be hex-escaped:

  • ":" (as in "C:") and "/" on Windows? I've seen programs use the latter as directory separator even on Windows. Others?
  • 8-bit chars in case the OS gets clever about charset handling.
  • Control chars.

  I don't use Windows myself though. Nor Mac...

Again, the rules for URL encoding probably already cover any cases we should worry about.

I don't think so. At least "/" is not "unsafe", if I read it right.

...

• RDNs ending with ".ldif" should be escaped. Currently "cn=foo.ldif" is the name of both RDN "cn=foo"'s entry file and RDN "cn=foo.ldif"'s non-leaf directory.

Perhaps we should escape '.'

Hm, true. "." is (was?) a special character on some filesystems. E.g. a file can only have one of them, or the 2nd is followed by a version number.

...

• Sorted-value RDNs:

No reply? :-) Ok, sort order can be adjusted separately anyway. One error in my previous attempt: bconfig.c mentions "pseudo-indexed" entries (cn=Include{xx}, cn=Module{xx}) which I presume must be sorted by {xx} too, so back-ldif can't treat only "attr={number}val" as indexed. I guess I'll either check both variants or allow {number} anywhere, depending on convenience.