(Note: feel free to say "not a bug" or offer a workaround rather than changing ikiwiki.)
As reported by a Windows user trying ikiwiki: because Windows doesn't support filenames with colons, he couldn't check out the ikiwiki svn repository. More generally, ikiwiki doesn't encode colons in filenames for wiki pages, but to support Windows users perhaps it should.
Windows does not support filenames containing any of these characters:
/ \ * : ? " < > |
I take it this is a problem when checking out a wiki in windows, not when browsing to urls that have colons in them from windows? --Joey
Correct. You can't directly check out a wiki's repository from Windows if it includes filenames with those characters; you will get errors on those filenames.
Ok, first, if a windows user fails to check out ikiwiki's own svnWgit repo on windows due to the colons, that seems to be a bug in svnWgit on windows -- those programs should deal with colons in filenames being checked in/out somehow. Like they deal with windows using backslash rather than slash, presumably. And there's nothing ikiwiki can do if the source repo it's working on has a file with a problem character added to it, since the breakage will happen at the revision control system level.
Just a quick note that the version control community generally doesn't agree with that view. They'll store what you ask them to store. If you want to work cross platform, then you need to make sure that all your file names work on all the platforms you're interested in. (Note: many systems will warn on commit, but not all. Many systems also have a way to fix the problem without checking out, but not all.) Another common place for this to arise is case insensitive file systems. If you have two files committed that differ only in case, then you cannot check out on a Mac in most systems.
OTOH, there are some simple mods to ikiwiki that can make it escape colons etc the same way it already escapes other problem characters like "*", "?", etc. Without actually testing it, it should suffice to edit
linkpage, removing the colon from the character class in each. Also modify the
wiki_file_regexpsimilarly. Then ikiwiki will read and write files with escaped colons, avoiding the problem.
So that's a simple fix, but on the gripping hand, I can't just make that change, because it would break all existing unix-based wikis that actually contain colons in their filenames, requiring an annoying transition. I could do a OS test and do it in Windows, but then there would be interop problems if a Windows and non-windows system both acted on the same wiki source.
I haven't checked the source, but need this break existing wikis? I can imagine a system where a colon gets converted to something safe, and the safe encoding gets converted back to a colon. But if you already have a colon, that doesn't get converted and stays a colon, and so it should still work shouldn't it? The only problem would be with pages that already have the 'safe encoding for a colon'. They'll suddenly change names. Well, I should finish frying my current fish before taking on something new, so I'll shut up now :). -- Will
linkpage()is changed to escape colons, then links to pages with literal colons in their names will stop working; ikiwiki will instead look for page names with escaped colons. --Joey
So, I guess it has to be a config option, possibly defaulting on when the OS is Windows. And if being able to checkout/etc the wiki source on windows systems is desired, you'd have to remember to turn that on when setting up a wiki, even if the wiki was hosted on unix.
wiki_file_charsconfig option added, set to
"-[:alnum:]+/._"to exclude colons from filenames read or written by ikiwiki. done
BTW, I suspect there are lots of other problems with actually running ikiwiki on windows, including its assumption that the directory separator is "/". Windows will be supported when someone sends me a comprehansive and not ugly or performance impacting patch. --Joey
Speaking of Windows filename problems, how do I keep directories ending in a period from being created? The following didn't seem to work.
wiki_file_chars => "-[:alnum:]+/._",
wiki_file_regex => '[-[:alnum:]+_]$',