On Tue, Nov 20, 2012 at 8:59 AM, Jan Nijtmans <[email protected]>wrote:
> 2012/11/19 Stefan Bellon <[email protected]>: > > 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 > > > > \ / : * ? " < > | > > An EXPERIMENTAL fix is committed now in [82ce90f91c]. It > handles the invalid characters in the same way as cygwin > does: <http://cygwin.com/cygwin-ug-net/using-specialnames.html> > In cygwin it is no problem at all to use such characters in > filenames, except for the backslash. I found ':' problematic > as well, as it is used in UNIX as path separator (path1:path2) > and on Windows as drive separator (C:\foo). > I think that there needs to be two separate versions of fossil_utf8_to_unicode(), or perhaps a parameter on one function, so that some strings can get the conversion of problematic characters to the unicode private-use range, while others go unaltered. Clearly, any string that is used as a filename gets converted. But, for example, the password for the "fossil winsrv create" command should not get the character conversions, because characters like * ? " < > and | can legitimately occur in passwords. Some uses are less clear. For example, at http://www.fossil-scm.org/fossil/artifact/33d79f5b0a2?ln=850 we are converting an entire command-line, which does likely contain some filenames, but also might contain other text where *?"<>| are legitimate characters. I think doing the conversion will work OK for every case where Fossil calls fossil_system(), but we need to be careful here. Perhaps two functions: fossil_filename_to_unicode() // Does the conversion fossil_utf8_to_unicode() // Omits the conversion Or else a extra boolean parameter to fossil_utf8_to_unicode() that enables/disables the conversion. > > The advantage of this method is that using a cygwin-compiled fossil > will have exactly the same result as using a win32 version of fossil. > The cygwin shell will show all filenames as they are expected to > be. From Windows explorer they might look strange, but > nothing goes wrong. > > The only remaining problematic characters are '\' and ':', all > others are - on Windows - translated to a safe Unicode range. > At this moment I don't see a way to work around the two > remaining problematic characters. > > I think this deserves a lot more testing. I will.... > > Regards, > jan Nijtmans > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
