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.