Script Name Casing Duplicates

[TimidScript]

If you change the casing of your script name you are unable to access latest version.

Steps I took and the bug it created.

I had a script name with the word "deviantART" I changed it to "DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script listing the name remains "deviantArt", but the version is 1.0.6. When you try and install or look the code, it points to 1.0.5. I fixed it by updating the script again but with the old casing "deviantArt". There might be a script floating around in the database with the name "DeviantArt", that's not deleted.

(Making the user and script name as the UID causes some painful limitations to the script author. On top breaking auto-update, the install counter resets.)

[Martii]

This is more or less a duplicate but important enough to keep tracking as an individual issue as a watch point with the parent milestone. Thanks for the report.

[sizzlemctwizzle]

We identify scripts by @name and @namespace, which are both case-sensitive.
You created a new script when you changed the name. Even Greasemonkey would
have recognized it as a different script with the name change.
On Jul 2, 2015 8:56 AM, "TimidScript" notifications@github.com wrote:

If you change the casing of your script name you are unable to access
latest version.

Steps I took and the bug it created.

I had a script name with the word "deviantART" I changed it to
"DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script
listing the name remains "deviantArt", but the version is 1.0.6. When you
try and install or look the code, it points to 1.0.5. I fixed it by
changing the updating the script again but with the old casing
"deviantArt". There might be a script floating around in the database with
the name "DeviantArt", that's not deleted.

Making the user and script name as the UID causes some painful limitations
to the script author. On top breaking auto-update, the install counter
resets.

—
Reply to this email directly or view it on GitHub
#656.

[sizzlemctwizzle]

However this bug might be the result of case-insensitivity in the actual
URL.
On Jul 2, 2015 3:30 PM, "Michael Medley" medleymind@gmail.com wrote:

We identify scripts by @name and @namespace, which are both
case-sensitive. You created a new script when you changed the name. Even
Greasemonkey would have recognized it as a different script with the name
change.
On Jul 2, 2015 8:56 AM, "TimidScript" notifications@github.com wrote:

If you change the casing of your script name you are unable to access
latest version.

Steps I took and the bug it created.

I had a script name with the word "deviantART" I changed it to
"DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script
listing the name remains "deviantArt", but the version is 1.0.6. When you
try and install or look the code, it points to 1.0.5. I fixed it by
changing the updating the script again but with the old casing
"deviantArt". There might be a script floating around in the database with
the name "DeviantArt", that's not deleted.

Making the user and script name as the UID causes some painful
limitations to the script author. On top breaking auto-update, the install
counter resets.

—
Reply to this email directly or view it on GitHub
#656.

[Martii]

which are both case-sensitive

Yup... and when we move to _id we'll need to watch that someone doesn't completely change the @name to something totally different but still have it access via the old @name, etc. URL but have GM install it under the new @name.

Honestly I'd rather just like to have a comparison of old to new and create a new indexed script... and if the toLowerCase of the url matches then possibly prompt. The basic moral here is don't change the core UserScript metadata items... will be a bit tricky to handle the logic but I think it's quantifiable since we do this for discussions already.

[TimidScript]

Even Greasemonkey would have recognized it as a different script with the name change.

GM keeps the same local storage name if you download from same place, no matter what changes you make to the meta. Old USO, GreasyFork, Gist and Github have same unquie id. All the sites you can rename and still have a unique id to keep track of the original.

Anyway, I renamed the script without much thought. I forgot about OUJS unique behaviour.

[Martii]

If you change the casing of your script name you are unable to access latest version.

Type checks for owned re-casing test:

• Existing script edit - change @name and any changes in entire script are omitted
• Write script online - change @name and any changes in entire script are omitted
• Upload script - change @name and any changes in entire script are omitted
• Sync - pending... will have to do this at dev station since this location doesn't allow ssh connections here yet GRR

---

• Changing @version and @name does affect Raw JSON data. e.g. OUJS stored metadata ... this may be the bug here
• Script source remains original source.

Conclusion... duplicate script made in DB with shared OUJS metadata.

---

However this bug might be the result of case-insensitivity in the actual URL.

Possibly in find* routines... not showing duplicate in script list... added security label for this part.

[TimidScript]

FYI: GM is case-insensitive.

[Martii]

FYI: GM is case-insensitive.

FYI: It shouldn't be... it should be case sensitive and is reconfirmed here. (Meta keys and values, even at the file system level, with lower case a and upper case A are different scripts)

Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 SeaMonkey/2.33.1
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 (38.0.1 distro build)
Most recent GMs for each browser

Invalid for that portion of this report.

Further GM engine refs:

• case-insensitive meta block @keys greasemonkey/greasemonkey#1097
• @updateURL and @downloadURL are case-sensitive greasemonkey/greasemonkey#1679

[TimidScript]

Odd, retested it and you are right. First time I time I tested it, I had a script called "TEST" and "test" and one overwrote the other. Tried again and not the case. Must have made a mistake.

[Martii]

@sizzlemctwizzle
Misc. note(s):

• Base issue where this was "corrected" was found being referenced in Stop using @namespace to identify scripts #130 ... with commit 5b65abd
• Period of time reminder is when you fixed my "marti" to "Marti" username access in the URI... e.g. case insensitivity on Usernames... but the installSlugName is completely case insensitive now which includes the Scriptnames... which is a cause for this issue. (e.g. miss at Stop using @namespace to identify scripts #130 (comment) ) There may be more since then... but this is where I got a trial and error hit with seeing the missing scripts in my own investigation... which led me to the referenced issue list item and eventual commit.
• We might not be able to change caseInsensitive search for a path separator as some script names I've seen some that do have a slash in them although I don't know for sure if they are escaped (encodeURI...) or not.

[Martii]

@TimidScript
You should be able to change your casing now... it will by design spawn a new script on OUJS (if script homepage doesn't exist for you) as @sizzlemctwizzle mentioned. Let me know how it goes.

My production Unit Tests are currently here and HERE.

[TimidScript]

@Martii
Thank you. Just tested it and it seems to work. I won't be renaming anything, as it will produce a new link for the homepage and all stats will be lost.