Last modified: 2014-09-09 17:41:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42326, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40326 - File extension letter case treatment should be unified on Commons
File extension letter case treatment should be unified on Commons
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Bryan Tong Minh
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 10:09 UTC by Marek Blahuš
Modified: 2014-09-09 17:41 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Marek Blahuš 2012-09-18 10:09:03 UTC
Currently, the UploadWizard accepts an upper case file name extension (i.e. JPG), does not change it but neither allows the user to do so (see bug 34703). Therefore, it is possible to upload two files, one ending in .jpg and the other .JPG.

However, elsewhere on Commons, such as in the RenameLink gadget or the tool used by filemovers, .jpg and .JPG are considered the same and the tools won't allow renaming between these two variants, therefore making it impossible to repair consistency if a series of pictures have been uploaded using one case with only one or a few of them accidentally using another case. All these tools seem to share a common "file name sanitization" module, as reported at http://commons.wikimedia.org/wiki/User_talk:Rillke#RenameLink_forces_case_in_file_extension

As evidenced at https://commons.wikimedia.org/wiki/User_talk:Blahma#File:Brno.2C_T.C3.A1bor_15.jpg file movers need to rename files manually if they are requested to change letter case in file extension, such as renaming "foo.JPG" to "foo.jpg".

File names should be treated equally everywhere on Commons, so if file name extensions get "normalized" by file moving tools, the same "sanitization" should be performed in the UploadWizard.
Comment 1 Bryan Tong Minh 2012-09-18 12:43:39 UTC
There are some checks in place, but they only work if the existing file has the normalized extension, i.e., a warning will be given if you try to upload X.JPG and X.jpg exists, but not the other way around. 

It is probably a good idea to just give a warning if the same filename exists with any extension. That would need support in FileRepo to search files without extension. I'll have a look at it.
Comment 2 Bryan Tong Minh 2012-09-18 13:16:44 UTC
I21eddc5d
Comment 3 Marek Blahuš 2012-09-18 15:51:17 UTC
Thank you, Bryan, for your quick response and act. It would inded be nice to see a warning when a similarly named file already exists.

However, this does not solve the problem completely, because it means that the Upload Wizard will go on stating that "file names differing only in extension case are possible", while the tools that might be used subsequently (file renaming) state "file name extensions must be normalized as if they were case-insensitive". This means that confusion will persist, unless a consensus on this is found across Commons. Perhaps we should invite more people into this discussion?

The easiest solution is, obviously, to equip the Upload Wizard with the same "sanitization" mechanism which is already used by the file mover, but I understand that this is not something what you are willing to do at the moment, am I right?
Comment 4 Bryan Tong Minh 2012-09-20 17:23:22 UTC
I'm not aware of any software restrictions on file moving that perform the normalizations you describe. As far as I am aware it is possible to move a file to A.JPG if the file A.jpg already exists.
Comment 5 Marek Blahuš 2012-09-20 23:10:04 UTC
I have found the "cleanFileName" function from http://commons.wikimedia.org/wiki/MediaWiki:Gadget-AjaxQuickDelete.js being called as a part of https://commons.wikimedia.org/wiki/MediaWiki:RenameRequest.js which holds the code for the RenameLink gadget. Indeed, when you are not a file mover, visit a file page and click the "Move" tab, the gadget's dialog appears and there if you change the value in the "Enter the new name" field to "A.JPG" and leave that field by focusing another one, cleanFileName gets called and the field's value is automatically normalized to "File:A.jpg".

Yes, I could insert the Rename template manually, but the gadget seems to be more efficient.

And, I am not a filemover so I cannot check myself, but User:Taketa has suggested at http://commons.wikimedia.org/w/index.php?title=User_talk%3ABlahma&diff=77628385&oldid=77600880 that the same normalization occurs in the actual filemoving interface (and is the cause of .JPG and .jpg considered "identical"). Could someone please recheck this?
Comment 6 Jesús Martínez Novo (Ciencia Al Poder) 2012-12-22 15:44:37 UTC
(In reply to comment #2)
> I21eddc5d

Assigning bug to author ( of Gerrit change #24124 ), +patch-in-gerrit
Comment 7 Nischay Nahata 2013-03-10 20:12:44 UTC
Is this fixed? The patch got merged.
Comment 8 Bawolff (Brian Wolff) 2013-05-10 01:36:23 UTC
(In reply to comment #1)
> There are some checks in place, but they only work if the existing file has
> the
> normalized extension, i.e., a warning will be given if you try to upload
> X.JPG
> and X.jpg exists, but not the other way around. 
> 
> It is probably a good idea to just give a warning if the same filename exists
> with any extension. That would need support in FileRepo to search files
> without
> extension. I'll have a look at it.

People seem to want to be able to do that though. See bug 46741
Comment 9 Mark Holmquist 2014-09-09 17:41:06 UTC
Looks like this is just about done - I don't think it's necessary to change the filenames to have the same extensions in UW. I got the warning reliably by uploading a .jpg and .JPEG with the same name.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links