On Mon, Sep 30, 2013 at 9:57 PM, j. van den hoff <veedeeh...@googlemail.com>wrote:
> it is already done for blanks) when the "tarball URL" is constructed: > after all, the project name is just the descriptive title at the top of the > web-page and it feels not right to enforce that this title is also a "valid > file name". > If i'm not mistaken, the project's name is used as the top-most directory name in the tar/zip file, which means you might not be able to unpack the such a zip/tar if it contains ':' or '/' in it. Encoding it for the URL is not a problem (in principal, at least), though there might be a corner case or three waiting for us there. Way back in the old days, the zip files (fossil didn't have tar back then) unpacked everything into the current directory. At some point we added an "artificial" subdir based off of the project's name and the version UUID. At the time it was assumed (my fault!) that project names would be "simple" in nature, but that was (in hindsight a poor assumption). In baseline_zip_cmd() the code can be found which replaces space with underscore, but that's just a very basic form of escaping. To handle /, :, \, *, and probably a few other potentially problematic ones, we'd need to expand that (and the corresponding tar counterpart) a bit (but it's almost bedtime here, so i'm not going to touch it tonight ;). Ah, here's a workaround which might work: pass a name=abcdef option and it will use that as the base name, but if it's longer than 10 bytes then it truncates it to 10 bytes (see zip.c:baseline_zip_page()). i haven't checked the corresponding tar code to see if it has a similar feature. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
