On Mon, 19 Nov, Richard Hipp wrote: > I made the decision to disallow "problematic" characters in Fossil > filenames 6 years ago. In theory, Fossil could allow these > characters in filenames. But doing so would enhance the potential > for bugs and would greatly complicate testing of the code. And I > didn't see any value in doing so. Simpler is better.
Yes, agreed. The question is just whether restricting characters is "simpler" or whether those special Windows exclude rules are rather "more complicated". See below for the reasoning. > The code that checks for valid filenames is here: > > http://www.fossil-scm.org/fossil/artifact/91e4570f9462?ln=479-513 I think this restriction * Does not contain any of these characters in the path: "\*[]?" is too arbitrary. If you try to create a file or directory in the Windows explorer and type e.g. a " then you get a bubble help with the information that you must not use any of the following characters \ / : * ? " < > | So either all of those should get rejected by fossil's pathname filter or none at all. But if all of those get rejected, there may be other operating systems out there which have other restrictions (e.g. RISC OS does not allow for a full stop in a filename because . and / are swapped in RISC OS' file system). The above restricted characters are just the ones for Windows. In fact you get into the same kind of trouble with casing as well. On case-sensitive file systems you can add files called foobar.txt FooBar.txt FOOBAR.TXT and so on. But you cannot check them out on a case-insensitive file system (like on Windows) because they would end up in the same file. If you wanted to make sure this cannot happen, you'd have to forbid adding differently cased versions of a filename on e.g. UNIX just because it could cause trouble checking out on Windows. That leads me back to my original statement that I think that "simple" means allowing all filenames. I think the "checkout" code that creates files should be able of handling such failures (warn the user but continue) instead having the "add" code decide whether a filename is "nice enough". > You are welcomed to modify this in any way you see fit. If you want > to submit a patch, we will consider adding it. I'm not yet familiar with fossil's code and what consequences a change at this code part could mean for other areas, i.e. which assumptions on filenames in fossil's internal data structures exist elsewhere. Therefore I'm a bit reluctant to perform such a change myself. Greetings, Stefan -- Stefan Bellon _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
