Re: (ITS#5408) back-ldif bugs

[h.b.furuseth@usit.uio.no]

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.

-- 
Hallvard