coming back to this problem of "problematic" character such as `/' causing
tar/zip download to fail since the
URL generated by fossil is invalid: would it not be sensible to simply use
as name the sha1 hash itself plus the suitable extension,
e.g something like
ae9ca63258d41bda7b7ca968b65ddecaef1a742b.zip (or, preferably,
abbreviated to 10 chars of the hash as in the timeline)?
this seems to have 3 advantages:
1) no interference anymore with user's choice of project name and valid
file name on all platforms
2) file name still sufficiently "unique" to avoid accidental names clashes
on the local disk
3) it should be the path of least resistance regarding fixing it in the
source code
renaming of the unpacked archive directory to something more recognizable
(if so desired) might be left as an exercise to the user I'd say ...
j.
On Mon, 30 Sep 2013 22:29:26 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
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.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
