Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-37761

case in spelling of jobname doesn't matter on downloadign using wget

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
    • Environment:
      Jenkins 2.17 running on RH Linux
    • Similar Issues:

      Description

      When I try to create jobs like

      1. foo
      2. FOO
      3. Foo
      4. fOo
      5. ...
        Jenkins will only allow me to create the first one. After that, it complains that a job of this name already exists. (It uses the case of the job, I just try to create)
        [I'm mildly surprised, because this is Unix, where case matters]

      The bad thing comes, when I try to download the job using
      http://<jenkins>:<port>/view/Admin/view/All/job/FOO/config.xml
      Here I can use whatever case for 'FOO' (e.g. all of the above) and each of the downloads succeed.
      I would expect to only be able to download the job with the correct case. (Yielding an error in all other cases)

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          So what's the bug here? That Jenkins behaves consistently in treating job names case-insensitively?

          Show
          danielbeck Daniel Beck added a comment - So what's the bug here? That Jenkins behaves consistently in treating job names case-insensitively?
          Hide
          danielbeck Daniel Beck added a comment -

          Job names are deliberately case insensitive:
          https://github.com/jenkinsci/jenkins/blob/952c5e250ee961af5dddd879323dbb32e3fde41d/core/src/main/java/jenkins/model/Jenkins.java#L452

          This has been in there forever. Since Jenkins is a cross-platform tool and creates directories on disk corresponding to job names, the lowest common denominator (case-insensitive file systems) needs to be considered.

          Changing it would result in regressions for no real reason, so I'm resolving as Won't Fix.

          Show
          danielbeck Daniel Beck added a comment - Job names are deliberately case insensitive: https://github.com/jenkinsci/jenkins/blob/952c5e250ee961af5dddd879323dbb32e3fde41d/core/src/main/java/jenkins/model/Jenkins.java#L452 This has been in there forever. Since Jenkins is a cross-platform tool and creates directories on disk corresponding to job names, the lowest common denominator (case-insensitive file systems) needs to be considered. Changing it would result in regressions for no real reason, so I'm resolving as Won't Fix.
          Hide
          martinjost Martin Jost added a comment -

          While this is ok for a case smashing but preserving FS (Windows), it is IMHO still bad for a case sensitive one (Unix).
          If the GUI of Jenkins restricts me to the first case-variant I create, I would expect Jenkins to also only allow me to download the job under this name.

          On Windows I would not get another name on the local FS, because all case variants are considered equal by the FS.
          (And Jenkins also considers all case variants as equal for the sake of these FS; this is fine with me - having just case differences between two jobs would be really confusing.)

          On Unix currently I can download 2^n case-variants, but still it is the same job. So for the sake of the case sensitive FS, only the spelling variant actually present in Jenkins should be downloadable. After all Jenkins decided to restrict to this one, so it should do this consistently.
          (And this is the change between current behaviour and the one I would expect)

          Did I just miss the point ? I'm still surprised by the behaviour. (And colleagues had been too....)

          Show
          martinjost Martin Jost added a comment - While this is ok for a case smashing but preserving FS (Windows), it is IMHO still bad for a case sensitive one (Unix). If the GUI of Jenkins restricts me to the first case-variant I create, I would expect Jenkins to also only allow me to download the job under this name. On Windows I would not get another name on the local FS, because all case variants are considered equal by the FS. (And Jenkins also considers all case variants as equal for the sake of these FS; this is fine with me - having just case differences between two jobs would be really confusing.) On Unix currently I can download 2^n case-variants, but still it is the same job. So for the sake of the case sensitive FS, only the spelling variant actually present in Jenkins should be downloadable. After all Jenkins decided to restrict to this one, so it should do this consistently. (And this is the change between current behaviour and the one I would expect) Did I just miss the point ? I'm still surprised by the behaviour. (And colleagues had been too....)
          Hide
          danielbeck Daniel Beck added a comment -

          After all Jenkins decided to restrict to this one, so it should do this consistently.

          The behavior is identical to what Windows file systems do, and internally consistent. It's case-insensitive ("does not care about letter case"), but case-preserving. Lookup of FOO, foo, and Foo succeeding and returning the same item is the corollary to not being able to create Foo and foo independently.

          Show
          danielbeck Daniel Beck added a comment - After all Jenkins decided to restrict to this one, so it should do this consistently. The behavior is identical to what Windows file systems do, and internally consistent. It's case-insensitive ("does not care about letter case"), but case-preserving. Lookup of FOO, foo, and Foo succeeding and returning the same item is the corollary to not being able to create Foo and foo independently.

            People

            • Assignee:
              Unassigned
              Reporter:
              martinjost Martin Jost
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: