Kathy explained an issue (perhaps found on the mailing list) that occurred when using the remote Greenstone server with client gli: if the client creates a collection with, amongst others, any a manually created subdirectory containing one or more docs, then when uploading the collection to the remote server, this subdirectory's path was denoted as import%7Csubdir. The %7C is url-encoding for the vertical bar. And vertical bar generally represents the directory separator, which our cgi program gliserver.pl decodes into the appropriate dir sep for the remote OS. However, in the case of a manually created subdir inside a remote collection, the %7C in the local import path (within the coll) that was uploaded to gliserver.pl wasn't being decoded by gliserver into vertical bar and subsequently decode into the directory separator. Instead, gliserver left it as %7C. Then this resulted in a new dir import%7Csubdir being created on the file system under the collection, instead of a folder called subdir inside the collection's import. I think I've now fixed this issue: gliserver.pl's upload_collection_file method does an extra decode step for %7C into the local dirsep, just before the usual step of decoding vertical bars into the local dirsep. I'm not entirely sure that this fix is the solution Kathy had envisioned, or whether the problem was just a symptom of a larger one, where all kinds of URL encodings should actually be decoded first. But the fix resolves the current problem without breaking anything else as far as I can tell, so I'm committing it before I forget.
