On Wed, Feb 17, 2010 at 5:21 PM, xor <xor at gmx.li> wrote:
> On Wednesday 17 February 2010 18:21:59 Matthew Toseland wrote:
>> + private static final boolean operatingSystemIsWindows() { // TODO: Move
>> to the proper class + try {
>> + return System.getProperty("os.name").toLowerCase().indexOf("win") >= 0;
>> + } catch(Throwable t) {
>> + return true; // :)
>> + }
>> + }
>>
>> IMHO this is dodgy, other OSs might have "win" in them. Normally we just
>> check if File.separator is "\".
>
> Generally if we're not on Windows then more characters are allowed in
> filenames so false positives are better than false negatives.Is there any form of Windows where the separator won't be "\"? > >> I am not convinced that the rest of the change is a good idea. For example >> allowing HTML markup in filenames might combine with sloppy code to cause >> problems. Allowing % in url's might again cause issues. Allowing pipes, >> <>, >> and spaces might cause problems with filenames copied to a shell. I guess >> it should depend on the configuration i.e. how paranoid the user is. > > I think you're being too paranoid here. Filenames are like one of the first > things which are implemented in a new operating system, if any operating > system is exploitable only via special characters in filenames then it is > not our problem. And we should just fix our % encoder instead of being > paranoid about problems with it. I guess I will have a look at it now.... The issue is more likely to lie in some shell script than in the OS itself. However, I agree, this is a minor concern and it would be better to allow such characters. (I suppose we could have a config option for the truly paranoid.) Evan Daniel
