comment
This commit is contained in:
parent
fcdbc892ed
commit
efdb13fca3
1 changed files with 30 additions and 0 deletions
|
@ -0,0 +1,30 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2020-11-02T17:38:34Z"
|
||||
content="""
|
||||
I think windows has a limit of around 256 characters on the total length of
|
||||
a path. (vs 4096 on linux)
|
||||
|
||||
So, even if ikiwiki had a way to limit the length of a page name,
|
||||
which could perhaps be done with `wiki_file_regexp`, that would not help,
|
||||
because several short page names can be nested into a path that ends up too
|
||||
long for windows. As is the case here; neither of the bug report filenames
|
||||
is too long, only the comments on them end up too long. Allowing posting a
|
||||
bug report but not commenting on it would not be good.
|
||||
|
||||
Since I am flatly NOT going to decouple the bug tracking repo from the
|
||||
source code repo, this seems to put me in the position of going around
|
||||
cleaning up things that happen to be too long for windows manually. Which I
|
||||
frankly, also do not want to do. I guess I'll take patches if people want
|
||||
to send them, but is this really how we want to spend our time?
|
||||
|
||||
(Also, renaming someone's bug report out from under where it was risks them
|
||||
not seeing a request for more information.)
|
||||
|
||||
Note that, windows provides ways to avoid these length limits, by prefixing
|
||||
paths with a sequence that avoids using a compatability layer that imposes
|
||||
them, and instead uses a more modern layer that has more reasonable limits.
|
||||
I think git-annex actually uses that itself, thanks to some improvements to
|
||||
ghc. git for windows could be made to also, I suppose.
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue