XML Import on Windows

[David E Jones-3]

This should now be handled better. For details see my comments in SVN  
rev 746292.

-David

On Feb 17, 2009, at 8:47 AM, Jacques Le Roux wrote:

> As I can't find a good solution, I thought that maybe we could use a  
> javascript function to change the value (Windows path with  
> backslashs) before it's encoded. But this means to have it  
> everywhere it's needed (for instance in contents..., etc.)
>
> What do you think ?
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> As this does not make sens (we are not dealing only with URL, I was  
>> stupid - actually hardly awake). I'm looking for a real
>> solution...
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> There is something I completly forgot to report about this  
>>> problem : canonicalize() is acceptinp escaped \ using traditionnal  
>>> \\
>>> (I
>>> also tried \\\\) Of course I tried before implementing my hack,  
>>> but this did not work either.
>>>
>>> BTW I don't see in which case the string ":\" located at position  
>>> 1 (ie a string corresponding to the regexp  ^.:\.*$) will be
>>> harmfull if backslashs are transformed to forward slashs since I  
>>> don't know so far a protocol represented with only 1 character.
>>> So
>>> a not encoded colon can't be found (so far) in a correct URL at  
>>> position 1 followed by a not encoded backslash.
>>>
>>> Am I overseeing something ? Else we could say that it's  
>>> deterministic as long as a protocol is not represendted by a sole
>>> character (an even in that case why shall we find backslash just  
>>> after ?)
>>>
>>> References:
>>> http://www.rfc-editor.org/rfc/rfc1738.txt
>>> https://kanis.fr/svn/trunk/wk/lisp/muse/muse-protocols.el
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> I just tried on demo server
>>>> input
>>>>   c:\quelque_chose\nimportequoi
>>>> error
>>>>   ERROR: reading file name (c:quelque_chosenimportequoi): null
>>>>
>>>> In debugger locally
>>>> input
>>>>   D:\workspace\ofbizRun\applications\ecommerce\data\DemoProduct.xml
>>>> canonicalized
>>>>   D:workspaceofbizRun
>>>>   plicationsìmmerceÚaÞoProduct.xml
>>>> Error
>>>>   ERROR: reading file name (D:workspaceofbizRun<br/
>>>> >plicationsìmmerceÚaÞoProduct.xml): null
>>>>
>>>> I meaned ugly :o)
>>>>
>>>> Jacques
>>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> On Feb 15, 2009, at 11:18 AM, Jacques Le Roux wrote:
>>>>>
>>>>>>> In other words, the information I have from both emails is  
>>>>>>> that  "it  doesn't work". But, WHY doesn't it work? HOW is it
>>>>>>> failing?  Any error  messages or other information about what  
>>>>>>> is actually  happening
>>>>>>
>>>>>>> (perhaps even the stuff I mentioned in my previous email  
>>>>>>> about  what  the canonicalized String that is causing the  
>>>>>>> problem
>>>>>>> looks
>>>>>>> like)?
>>>>>>
>>>>>> The canonicalized String (without my change) is ugly and I  
>>>>>> guess you  will not get much information from it.
>>>>>
>>>>> That's the point! It's great to know that it is ugly, but what  
>>>>> does  that MEAN?
>>>>>
>>>>> Actually my guess is that 100% of the information I need I'll  
>>>>> get from  that text. If I understand right the WHOLE problem with
>>>>> this is that  the string input by the user is being mangled so  
>>>>> the system can't use  it. Therefore the only really relevant
>>>>> details are:
>>>>>
>>>>> 1. an example of an original string that this is breaking
>>>>> 2. what that string looks like after it has been "mangled" by  
>>>>> the  canonicalization
>>>>>
>>>>> Chances are with just that information we can find a better  
>>>>> solution  to this.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

[Jacques Le Roux]

Brilliant!

Thanks David

Jacques

From: "David E Jones" <[hidden email]>

>
> This should now be handled better. For details see my comments in SVN  rev 746292.
>
> -David
>
> On Feb 17, 2009, at 8:47 AM, Jacques Le Roux wrote:
>
>> As I can't find a good solution, I thought that maybe we could use a  javascript function to change the value (Windows path with
>> backslashs) before it's encoded. But this means to have it  everywhere it's needed (for instance in contents..., etc.)
>>
>> What do you think ?
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> As this does not make sens (we are not dealing only with URL, I was  stupid - actually hardly awake). I'm looking for a real
>>> solution...
>>>
>>> Jacques
>>>
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> There is something I completly forgot to report about this  problem : canonicalize() is acceptinp escaped \ using traditionnal
>>>> \\
>>>> (I
>>>> also tried \\\\) Of course I tried before implementing my hack,  but this did not work either.
>>>>
>>>> BTW I don't see in which case the string ":\" located at position  1 (ie a string corresponding to the regexp  ^.:\.*$) will be
>>>> harmfull if backslashs are transformed to forward slashs since I  don't know so far a protocol represented with only 1
>>>> character.
>>>> So
>>>> a not encoded colon can't be found (so far) in a correct URL at  position 1 followed by a not encoded backslash.
>>>>
>>>> Am I overseeing something ? Else we could say that it's  deterministic as long as a protocol is not represendted by a sole
>>>> character (an even in that case why shall we find backslash just  after ?)
>>>>
>>>> References:
>>>> http://www.rfc-editor.org/rfc/rfc1738.txt
>>>> https://kanis.fr/svn/trunk/wk/lisp/muse/muse-protocols.el
>>>>
>>>> HTH
>>>>
>>>> Jacques
>>>>
>>>> From: "Jacques Le Roux" <[hidden email]>
>>>>> I just tried on demo server
>>>>> input
>>>>>   c:\quelque_chose\nimportequoi
>>>>> error
>>>>>   ERROR: reading file name (c:quelque_chosenimportequoi): null
>>>>>
>>>>> In debugger locally
>>>>> input
>>>>>   D:\workspace\ofbizRun\applications\ecommerce\data\DemoProduct.xml
>>>>> canonicalized
>>>>>   D:workspaceofbizRun
>>>>>   plicationsìmmerceÚaÞoProduct.xml
>>>>> Error
>>>>>   ERROR: reading file name (D:workspaceofbizRun<br/
>>>>> >plicationsìmmerceÚaÞoProduct.xml): null
>>>>>
>>>>> I meaned ugly :o)
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "David E Jones" <[hidden email]>
>>>>>>
>>>>>> On Feb 15, 2009, at 11:18 AM, Jacques Le Roux wrote:
>>>>>>
>>>>>>>> In other words, the information I have from both emails is  that  "it  doesn't work". But, WHY doesn't it work? HOW is it
>>>>>>>> failing?  Any error  messages or other information about what  is actually  happening
>>>>>>>
>>>>>>>> (perhaps even the stuff I mentioned in my previous email  about  what  the canonicalized String that is causing the
>>>>>>>> problem
>>>>>>>> looks
>>>>>>>> like)?
>>>>>>>
>>>>>>> The canonicalized String (without my change) is ugly and I  guess you  will not get much information from it.
>>>>>>
>>>>>> That's the point! It's great to know that it is ugly, but what  does  that MEAN?
>>>>>>
>>>>>> Actually my guess is that 100% of the information I need I'll  get from  that text. If I understand right the WHOLE problem
>>>>>> with
>>>>>> this is that  the string input by the user is being mangled so  the system can't use  it. Therefore the only really relevant
>>>>>> details are:
>>>>>>
>>>>>> 1. an example of an original string that this is breaking
>>>>>> 2. what that string looks like after it has been "mangled" by  the  canonicalization
>>>>>>
>>>>>> Chances are with just that information we can find a better  solution  to this.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>