commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Date Sun, 06 Jun 2010 15:53:57 GMT

    [ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876049#action_12876049
] 

Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------

Thanks for the proposed patch. It solves the problem described by this issue, but unfortunately
causes another unit test to fail.

Our rules for escaping list delimiters and other escaping characters have become so complex
that it is easy to lose overview. Per default, a comma is interpreted as list delimiter character.
This can be escaped by a backslash as in
{{options = 1\, 2 or 3}}.

Now there is often the requirement to store path names in configuration files. In Windows
environments this can cause problems with the escaping of the list delimiter, e.g.:
{{test.dirs = C:\\Temp\\,D:\\data}}

Here the trailing backslash of the first list element would be interpreted as escape character
for the list delimiter. Therefore it is also possible to escape the escape character for the
list delimiter:
{{test.dirs = C:\\Temp\\\\,D:\\data}}
This is the reason for the condition {{&& c != LIST_ESC_CHAR}} which your patch removed.

In your case you use names of network shares starting with a double backslash. If multiple
of these shares are declared in a single line using a list delimiter, these duplicated backslashes
are interpreted as escaped backslashes and so one of them is removed. This escaping is only
evaluated if a list delimiter is involved, so the properties actually have to look different
if they are defined in a single line or in multiple lines. I think, the user guide has to
be updated to reflect this.

To avoid escaping you have to duplicate the backslahes again. Your example then becomes:
{{test.share1 = \\\\\\\\share1a, \\\\\\\\share1b}}

However, when testing I found that there is still a bug in the escaping logic which does not
handle such constellations correctly. I am working on a fix.

> incorrect backslash parsing
> ---------------------------
>
>                 Key: CONFIGURATION-418
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.6
>         Environment: Commons Configuration 1.6
>            Reporter: Ricky Martin
>            Assignee: Oliver Heger
>            Priority: Minor
>         Attachments: Main.java, PropertyConverter.diff, sample.properties
>
>
> I am using Commons Configuration (PropertiesConfiguration) and some of my data are windows
shares: \\share1 or \\share2. The problem is the parsing return different things depending
how the keys are defined. For example, these keys
> share=\\\\share1
> share=\\\\share2
> are different than:
> share=\\\\share1, \\\\share2
> The first one returns two backslashes ("\\share1" and "\\share2") and the second returns
just one ("\share1" and "\share2"). I think the problem is in PropertyConverter line 525,
cos the backslash is hidden twice when multivalue parsing is done:
> if (c != delimiter && c != LIST_ESC_CHAR) 
>                 {
>                     // no, also add escape character
>                     token.append(LIST_ESC_CHAR);
>                 }
> In my understanding the second condition produces this strange issue and it should be
like this:
> if (c != delimiter) 
>                 {
>                     // no, also add escape character
>                     token.append(LIST_ESC_CHAR);
>                 }
> Check that cos I can be missing something...
> TIA

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message