UploadWizard unable to override "similar name"/"same name" detection warning
Closed, ResolvedPublic

Older changes are hidden. Show older changes.
McZusatz added a comment.Via ConduitApr 10 2013, 5:20 PM

Would be nice to know why this was introduced (and when)... Nevertheless it 'could' be useful considering it was possible to upload files like:
*movie.ogv
*movie.webm
*movie.ogg
containing all the same content.

(In reply to comment #1)

Hi, did you use http://commons.wikimedia.org/wiki/Special:UploadWizard or
http://commons.wikimedia.org/wiki/Special:Upload for uploading? (It's always
highly welcome to provide exact steps to reproduce, in order to avoid
ambiguity.)

What would be good reasons to relax that restriction? If you automatically
convert from e.g. svg to png you'd run into filename collisions.

Both are affected (UpWiz and old upload form)

(In reply to comment #2)
Clumsy workaround: You can still upload the file to any random name and move it directly after upload to the wanted name.

Bawolff added a comment.Via ConduitMay 10 2013, 1:27 AM

Seems to be introduced in I21eddc5d08ca3c23b3 / bug 40326

Bawolff added a comment.Via ConduitMay 10 2013, 1:31 AM

(In reply to comment #4)

Seems to be introduced in I21eddc5d08ca3c23b3 / bug 40326

It seems to me that this should be a "recoverable warning" (By which I mean you ask the user if they are sure, and then let them do it if they really want to). Does that sound right?

bzimport added a comment.Via ConduitMay 10 2013, 10:30 AM

davidrichfield wrote:

That would solve my problem, and I guess it would still avoid the problem in Bug 40326.

This would also allow a user to make an intelligent choice, for example if I want to upload steroidogenesis.svg and there's already a steroidogenesis.png, I can either keep the filename if I'm just making an svg version of the png, or change the name if it's a completely different picture.

Rillke added a comment.Via ConduitMay 28 2013, 10:57 AM

(In reply to comment #5)

this should be a "recoverable warning"

Recoverable only if it has a different file extension/type. Uploading Foo.JPG and Foo.jpg should be still impossible (as some file systems do not like this; Just imagine, their MD5 would start with the same byte).

bzimport added a comment.Via ConduitMay 28 2013, 10:54 PM

kevjonesin wrote:

Recoverable with a different file extension/type sounds good to me.

I'd recently added transparent backgrounds (alpha channels) to some .jpg images via [[GIMP]] and was a bit irked/befuddled when I'd entered info for multiple .png versions I was uploading simultaneously via UploadWizard only to get denied at the end. At the very least it would be nice if the filename denial had come nearer the start of the process. Of course a "recoverable warning" would make this moot... well, perhaps not... it would still be nice to get warnings regarding filenames as soon as the file name is entered via the file browser. Before going through additional steps.

Advance 'tanx' goes out to those with the skillz, : }

bzimport added a comment.Via ConduitMay 28 2013, 10:59 PM

kevjonesin wrote:

p.s. I'm...
[[User:Kevjonesin|Kevjonesin]] ([[User talk:Kevjonesin|talk]]) 22:58, 28 May 2013 (UTC)
...on English Wikipedia.

Aklapper added a comment.Via ConduitMay 29 2013, 12:09 PM

Bryan.TongMinh: Could you take a look at this, as https://gerrit.wikimedia.org/r/#/c/24124/ was written by you? Thanks.

McZusatz added a comment.Via ConduitJun 20 2013, 6:37 PM

Please fix this bug or revert the initial commit. This should not stay the way it is now.
FYI: I wasted some hours with debugging some python script because I could not upload a WebM file. Some minutes ago I realized another file was already uploaded with the same name (totally unrelated) with PNG extension.

Even if there are two related files like "animal123.png" & "animal123.webm" the error should not show up!

Bawolff added a comment.Via ConduitNov 7 2013, 4:29 AM

Is this still an issue on commons. (I was going to review your commit [Sorry about letting that fall through the cracks] today), but I couldn't reproduce the issue locally. Although it may be me just getting a little sleepy and doing something stupid

McZusatz added a comment.Via ConduitNov 7 2013, 5:30 PM

(In reply to comment #12)

Is this still an issue on commons?

Jup!

McZusatz added a comment.Via ConduitNov 8 2013, 10:07 AM

Related Patch set:
Change 87020
Change-Id I1a98bf43284b5045b1ee6c60e64075404fd0a837

https://gerrit.wikimedia.org/r/#/c/87020/

Bawolff added a comment.Via ConduitNov 15 2013, 6:25 PM

(In reply to comment #13)

(In reply to comment #12)
> Is this still an issue on commons?
Jup!

Really, because I was able to successfully upload https://commons.wikimedia.org/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.png even though https://commons.wikimedia.org/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.jpg exists

McZusatz added a comment.Via ConduitNov 15 2013, 8:48 PM

It is not possible for me to use the UpWiz which gives me:

There is [/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.webm another file] already on the wiki with the same filename

in red textcolor regardless of me clicking on "Retry failed uploads".

Also youtube2mediawiki gives "Upload failed."

Bawolff added a comment.Via ConduitNov 15 2013, 8:50 PM

(In reply to comment #16)

It is not possible for me to use the UpWiz which gives me:

There is
[/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.webm
another file] already on the wiki with the same filename

in red textcolor regardless of me clicking on "Retry failed uploads".

Also youtube2mediawiki gives "Upload failed."

I would view that as an upload wizard bug in that it doesn't allow people to bypass warnings. It seems kind of silly to me to get rid of all non-critical warnings because upload wizard is not giving the option to the user to ignore them

McZusatz added a comment.Via ConduitNov 15 2013, 9:00 PM

(In reply to comment #17)
Makes sense, actually. I guess we better file a new bug as this one is quite stuffed?

Bawolff added a comment.Via ConduitNov 15 2013, 9:06 PM

(In reply to comment #18)

(In reply to comment #17)
Makes sense, actually. I guess we better file a new bug as this one is quite
stuffed?

Although it appears that originally this happened for Special:Upload too, We could probably just move this bug to uploadWizard component.

MarkTraceur added a comment.Via ConduitNov 15 2013, 10:10 PM

I guess we could add in a check to ignore the filename exists error if they're not actually identical - i.e. the extension is different. That sounds fine to me. As long as we warn the user in the description step.

McZusatz added a comment.Via ConduitDec 7 2013, 5:08 PM

Changing importance: This is not an "enhancement" but a major bug displeasing uploaders for months now.

Just two more examples:
https://commons.wikimedia.org/w/index.php?oldid=103108315
https://commons.wikimedia.org/w/index.php?diff=111356217

Aklapper added a comment.Via ConduitDec 9 2013, 12:23 PM
  • Bug 58186 has been marked as a duplicate of this bug. ***
Rillke added a comment.Via ConduitDec 18 2013, 7:27 PM

(In reply to comment #21)

I guess we could add in a check to ignore the filename exists error if they're
not actually identical - i.e. the extension is different. That sounds fine to
me. As long as we warn the user in the description step.

What would you like to "warn the user about"?

Aklapper added a comment.Via ConduitJan 2 2014, 10:48 AM

mtraceur: Could you answer comment 24 please?

MarkTraceur added a comment.Via ConduitJan 8 2014, 11:52 PM

Well, I would definitely like to tell the user that they're creating a potentially confusing filename. I won't make it *fatal*, but there should be notice of some sort.

Rillke added a comment.Via ConduitApr 16 2014, 10:19 PM

(In reply to Mark Holmquist from comment #26)

Any progress? Or can I author a patch?

McZusatz added a comment.Via ConduitApr 17 2014, 7:20 AM

(In reply to Rainer Rillke @commons.wikimedia from comment #27)
Please do. :)

Regardless whether you decide to include a warning or decide to drop them... Everything is better than the current state which blocks "valid" uploads and confuses uploaders.

AdamCuerden added a comment.Via ConduitJun 9 2014, 3:34 PM

This also causes problems with PNG/JPEG versions - JPEGs display better, but are lossy, so, with scans and restorations it's pretty normal to have both a JPEG and PNG. Up until recently, it was at least possible to upload both at once, it's blocked now.

AdamCuerden added a comment.Via ConduitJun 9 2014, 3:35 PM

(By which I mean that the recent patch actually made the uploads ''more'' restrictive.)

MarkTraceur added a comment.Via ConduitSep 10 2014, 8:25 PM

It looks like no work has been done on this, I'm going to try to whip up a patch now.

gerritbot added a comment.Via ConduitSep 10 2014, 10:31 PM

Change 159625 had a related patch set uploaded by MarkTraceur:
[WIP] Add override button back in

https://gerrit.wikimedia.org/r/159625

MarkTraceur added a comment.Via ConduitSep 11 2014, 4:03 PM

This is WIP because the issues with the prior patches still exists. I guess we need to finish refactoring before we can have any real solution here.

*weeping in the corner*

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:11 PM
Gilles moved this task to Next up on the Multimedia workboard.Via WebDec 4 2014, 8:43 AM
Gilles moved this task to Prototyping on the Multimedia workboard.Via WebDec 10 2014, 5:43 PM
Lokal_Profil added a subscriber: Lokal_Profil.Via WebJan 21 2015, 5:23 PM
Gilles moved this task to Untriaged on the Multimedia workboard.Via WebApr 6 2015, 9:22 AM
McZusatz added a comment.Via WebJul 11 2015, 9:50 PM

@all @MarkTraceur Is there any progress with doing the refactoring and then applying the patch?

Restricted Application added subscribers: Steinsplitter, Matanya. · View Herald TranscriptVia HeraldJul 11 2015, 9:50 PM
Aklapper added a comment.Via WebJul 26 2015, 8:43 AM

@MarkTraceur Is there any progress with doing the refactoring and then applying the patch?

McZusatz added a comment.Via WebJul 26 2015, 10:49 AM

If not, please add a blocking task for clarity.

Peachey88 removed a subscriber: Peachey88.Via WebJul 26 2015, 8:37 PM
Jdforrester-WMF moved this task to Backlog on the Multimedia workboard.Via WebSep 4 2015, 6:44 PM
matmarex claimed this task.Via WebSep 8 2015, 10:30 AM

I'm going to try untangling these issues this week.

matmarex changed the title from "UploadWizard unable to recover from warnings" to "UploadWizard unable to override "similar name"/"same name" detection warning".Via WebSep 9 2015, 4:46 PM
matmarex removed a project: Patch-For-Review.
matmarex set Security to None.
matmarex added a comment.Via WebSep 9 2015, 4:58 PM

T106968 has been merged into this bug incorrectly, this is a different issue that had incorrect title.

matmarex changed the task status from "Open" to "Stalled".Via WebSep 9 2015, 5:05 PM

I was unable to reproduce this issue locally.

I uploaded a file called "add.png" to my wiki: add.png

Then I separately uploaded another file, "add.svg": add.svg

Both files went through and I did not even get any warnings.

Is this still reproducible on Commons? (Please only stick to this particular issue of similar names being blocked; there are some other ways for an upload to break due to file names, that I'm debugging and tracking this work on T106968.)

McZusatz added a comment.Via WebSep 11 2015, 8:22 AM

Is this still reproducible on Commons?

4 minutes ago:

matmarex added a comment.Via WebSep 11 2015, 2:21 PM

Okay, but that's https://commons.wikimedia.org/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.jpg , and it looks like you're trying to upload another JPG file on top of it. Reuploading the same file with UploadWizard is currently not supported, per T42893: UploadWizard cannot replace existing files. This task (as I understand it, please correct me if I'm wrong) is about problems uploading a new file whose name differs from an existing one only at the extension.

matmarex changed the task status from "Stalled" to "Open".Via WebSep 11 2015, 5:16 PM

Thank you, I can reproduce now. Turns out that there is a separate issue where this warning (exists-normalized) is unintentionally suppressed by the warning about target file being previously uploaded and deleted (was-deleted), and that was preventing me from seeing it.

gerritbot added a subscriber: gerritbot.Via ConduitSep 11 2015, 6:51 PM

Change 237725 had a related patch set uploaded (by Bartosz Dziewoński):
UploadBase: Return 'was-deleted' warning in addition to 'exists-normalized', not instead of

https://gerrit.wikimedia.org/r/237725

gerritbot added a project: Patch-For-Review.Via ConduitSep 11 2015, 6:51 PM
matmarex added a comment.Via WebSep 11 2015, 7:24 PM

The patch above only fixes the was-deleted issue, it doesn't resolve this bug yet.

This is less than trivial because the same warning code exists-normalized is used both for cases where trying to upload "Foo.jpg" clashes with "Foo.ogg" and cases where it clashes with "Foo.JPEG". We want to allow the former and not the latter, and for that we need to share the list of "synonym" extensions between JS and PHP code, and we should probably make it reusable, and so on.

gerritbot added a comment.Via ConduitSep 11 2015, 7:39 PM

Change 237732 had a related patch set uploaded (by Bartosz Dziewoński):
mediawiki.Title: Add normalizeExtension method

https://gerrit.wikimedia.org/r/237732

gerritbot added a comment.Via ConduitSep 11 2015, 8:18 PM

Change 237740 had a related patch set uploaded (by Bartosz Dziewoński):
Do not claim that a file with given name already exists if the extension differs

https://gerrit.wikimedia.org/r/237740

gerritbot added a comment.Via ConduitSep 11 2015, 8:18 PM

Change 237741 had a related patch set uploaded (by Bartosz Dziewoński):
Allow uploading files with the same name but different extension at once

https://gerrit.wikimedia.org/r/237741

matmarex added a comment.Via WebSep 11 2015, 8:28 PM

Patches required to fix this issue:

Patches that improve the behavior in some corner cases:

gerritbot added a comment.Via ConduitSep 11 2015, 8:45 PM

Change 237732 merged by jenkins-bot:
mediawiki.Title: Add normalizeExtension method

https://gerrit.wikimedia.org/r/237732

gerritbot added a comment.Via ConduitSep 11 2015, 8:51 PM

Change 237740 merged by jenkins-bot:
Do not claim that a file with given name already exists if the extension differs

https://gerrit.wikimedia.org/r/237740

Jdforrester-WMF moved this task to Done on the Multimedia workboard.Via WebSep 11 2015, 8:53 PM
Jdforrester-WMF closed this task as "Resolved".Via WebSep 11 2015, 9:12 PM
Jdforrester-WMF moved this task to Announce in next Tech/News on the user-notice workboard.
gerritbot added a comment.Via ConduitSep 15 2015, 3:46 PM

Change 237741 merged by jenkins-bot:
Allow uploading files with the same name but different extension at once

https://gerrit.wikimedia.org/r/237741

Johan moved this task to In current Tech/News draft on the user-notice workboard.Via WebSep 17 2015, 4:06 PM
Johan moved this task to Announce in next Tech/News on the user-notice workboard.
Johan moved this task to In current Tech/News draft on the user-notice workboard.Via WebSep 23 2015, 11:18 AM
Johan moved this task to Recently announced in Tech/News on the user-notice workboard.Via WebSep 23 2015, 11:50 AM
AdamCuerden added a comment.Via WebSep 24 2015, 9:01 AM

Thank you so much for this.

Quiddity moved this task to Archive on the user-notice workboard.Via WebOct 1 2015, 7:16 PM
gerritbot added a comment.Via ConduitOct 12 2015, 1:33 PM

Change 237725 merged by jenkins-bot:
UploadBase: Return 'was-deleted' warning in addition to 'exists-normalized', not instead of

https://gerrit.wikimedia.org/r/237725

Add Comment