bug in uploading new version on commons
Closed, ResolvedPublic

Description

with version 1.16alpha-wmf (r56482) I am not able to upload nev version of file to commons. It says that file with this name exists.

{{cs}}
Soubor s tímto názvem již existuje ve sdíleném úložišti. Pokud přesto chcete váš soubor načíst, vraťte se a zvolte jiný název.
File:$1
$1


Version: 1.16.x
Severity: major

bzimport added a project: MediaWiki-Uploading.Via ConduitNov 21 2014, 10:52 PM
bzimport set Reference to bz20677.
JAnD created this task.Via LegacySep 17 2009, 10:15 AM
bzimport added a comment.Via ConduitSep 17 2009, 2:18 PM

verszil wrote:

Also, if the page of the file has been deleted but there was no file, we get this kind of message : <Failed to calculate file hash; may be missing or damaged. Filename: mwrepo://local/temp/5/5a/20090917141156!Anthony_Bloomberg.jpg>
And upload is not possible.

bzimport added a comment.Via ConduitSep 17 2009, 4:56 PM

Abigor wrote:

I just tried to upload a newer version over a old photograph but I didn't get a error, I guess this problem is already fixed or was only a temporary problem?!

demon added a comment.Via ConduitSep 17 2009, 5:18 PM

CC'ing Michael, probably new-upload regression?

bzimport added a comment.Via ConduitSep 17 2009, 6:10 PM

mdale wrote:

I am also having trouble reproducing the error locally or on commons.

bzimport added a comment.Via ConduitSep 17 2009, 6:31 PM

ss755 wrote:

I just tried after reporting it wouldn't work earlier and it's still giving me the same error.

bzimport added a comment.Via ConduitSep 17 2009, 6:52 PM

mdale wrote:

...I have been able to recreate the delete then re-upload issue on commons but not locally... maybe an issue with the file-system setup on commons? or differences from trunk and wmf deploy>... doing some more testing.

brion added a comment.Via ConduitSep 17 2009, 6:57 PM

Steps for me to reproduce the has problem:

  1. go to http://en.wikipedia.org/wiki/File:Long_leg_hair.jpg
  1. save the image to local disk
  1. hit "Upload a new version of this image"
  1. Select the saved file from disk
  1. *uncheck* 'Ignore warnings'
  1. Click through the duplicate file warning
  1. get <Failed to calculate file hash; may be missing or damaged. Filename: mwrepo://local/temp/a/ad/20090917185303!Long_leg_hair.jpg>

Retrieved from "http://en.wikipedia.org/wiki/Special:Upload"

If I leave 'Ignore warnings' checked the file goes through on a single step; possibly the temporary file isn't getting moved properly into the uploads temp directory, so the next request can't find it. Or there may be something else wrong with the session handling.

Haven't seen the commons dupe warning, though.

bzimport added a comment.Via ConduitSep 17 2009, 7:50 PM

mdale wrote:

btongminh fixed in r56557 ... I did not have extensions like (fileBlacklist) installed locally (do now). Was an issue with virtual url being passed to the hook instead of the real url. We now init uploadFromStash with the real file url.

bzimport added a comment.Via ConduitSep 17 2009, 8:10 PM

verszil wrote:

I tried to upload the flickr image here : http://www.flickr.com/photos/joaomaximo/3339447124/ on the page here http://commons.wikimedia.org/wiki/File:2009_8_049_Kenya_Wasini_island.jpg using the upload it, now... And it doesn't work. Does the fiw has been loaded on Wikimedia servers ?

bzimport added a comment.Via ConduitSep 17 2009, 8:11 PM

Bryan.TongMinh wrote:

Now it does. Please try again.

bzimport added a comment.Via ConduitSep 17 2009, 8:19 PM

verszil wrote:

I'd just try again. When I specify every thing on the upload form and click upload file, it goes back to the upload form without loading the file.

bzimport added a comment.Via ConduitSep 17 2009, 8:34 PM

Bryan.TongMinh wrote:

Flickr Upload Bot is a toolserver service and not a MediaWiki function.

bzimport added a comment.Via ConduitSep 17 2009, 8:41 PM

verszil wrote:

It is not while using Flickr Upload Bot. I create the page with the bot and the bot seems to have an issue with the upgrade.

BUT I tried then to upload it from the commons interface. Going to this page : http://commons.wikimedia.org/wiki/File:2009_8_049_Kenya_Wasini_island.jpg Clicking on upload it and then specify a local file (that came from this page http://www.flickr.com/photos/joaomaximo/3339447124/) I test with or without checking the Ignore all warning...

Then, it just go back to the upload form. Without loading the file or providing an error.

bzimport added a comment.Via ConduitSep 17 2009, 8:49 PM

Bryan.TongMinh wrote:

(In reply to comment #13)

It is not while using Flickr Upload Bot. I create the page with the bot and the
bot seems to have an issue with the upgrade.

Yes, but that is an issue with the bot and not with MediaWiki, so this is not the appropriate forum for this. In any case I have fixed this issue with the bot.

bzimport added a comment.Via ConduitSep 17 2009, 8:59 PM

verszil wrote:

(In reply to comment #14)

(In reply to comment #13)
> It is not while using Flickr Upload Bot. I create the page with the bot and the
> bot seems to have an issue with the upgrade.
>
Yes, but that is an issue with the bot and not with MediaWiki, so this is not
the appropriate forum for this. In any case I have fixed this issue with the
bot.

I'm not speaking about the bot. Did you read :

BUT I tried then to upload it from the commons interface. Going to this page :
http://commons.wikimedia.org/wiki/File:2009_8_049_Kenya_Wasini_island.jpg
Clicking on upload it and then specify a local file (that came from this page
http://www.flickr.com/photos/joaomaximo/3339447124/) I test with or without
checking the Ignore all warning...

Then, it just go back to the upload form. Without loading the file or providing
an error.

bzimport added a comment.Via ConduitSep 18 2009, 12:24 AM

mbzmbz77 wrote:

It still does not work in Commons. I cannot overwrite my file with a new version.

bzimport added a comment.Via ConduitSep 18 2009, 12:55 AM

verszil wrote:

I tried to upload manually (without using a bot) the pictures in this cat : http://commons.wikimedia.org/wiki/Category:Image_pages_created_for_Flickr_upload_bot_without_files but I've got the same issue as before.

My process :

  1. I donwload the file from flickr page
  1. I go to the file page.
  1. As there is no file, I've got this message : "No file by this name exists, but you can upload it."
  1. I click on upload it.
  1. I arrived on the classical commons upload form.
  1. I click on Browse.
  1. I select the file.
  1. I click on Upload file.
  1. I go back to step 5 without error message or warning or upload of the file.
Melos added a comment.Via ConduitSep 18 2009, 9:16 AM

Created attachment 6562
Upload new version

Attached:

Melos added a comment.Via ConduitSep 18 2009, 9:17 AM

On itwiki autoconfirmed user can't upload a new file version (see attachment for error details), no problem instead with sysop rights.
Is it related to this bug or it is a separate issue? Thanks (sorry for double comment)

bzimport added a comment.Via ConduitSep 18 2009, 12:11 PM

cecilatwp wrote:

Just got the same complaint from an user at dewiki. But as an admin I am able to upload new versions on Commons (not tested on dewiki).

bzimport added a comment.Via ConduitSep 18 2009, 1:33 PM

mycae wrote:

CCing -- I have seen this a few times now.

bzimport added a comment.Via ConduitSep 18 2009, 5:46 PM

verszil wrote:

It is confirmed that on Commons, it's the same bug. Admins could upload a new version, other users can't.

bzimport added a comment.Via ConduitSep 18 2009, 7:48 PM

Bryan.TongMinh wrote:

(In reply to comment #19)

On itwiki autoconfirmed user can't upload a new file version (see attachment
for error details), no problem instead with sysop rights.
Is it related to this bug or it is a separate issue? Thanks (sorry for double
comment)

It is a different issue. I thought this restriction was in place before the new code as well, but please correct me if I'm wrong: Users can not upload an image which also exists under the same name as on Commons. Was this the previous situation as well?

bzimport added a comment.Via ConduitSep 18 2009, 8:02 PM

Bryan.TongMinh wrote:

(In reply to comment #17)

I tried to upload manually (without using a bot) the pictures in this cat :
http://commons.wikimedia.org/wiki/Category:Image_pages_created_for_Flickr_upload_bot_without_files
but I've got the same issue as before.

It appears to be a problem with Commons' Javascript hacks; if I disable JavaScript it works. I will investigate further, but this is not an issue with MediaWiki core.

Lupo added a comment.Via ConduitSep 18 2009, 9:22 PM

I don't think so. It fails for me (when I log in as a normal user) also with JavaScript completely disabled. Bryan suspected it had something to do with wpSourceType not being sent, but I verified this using Firebug: the POST request does contain that field, and in fact looks identical, whether commons:MediaWiki:UploadForm.js is used or not.

As I'm offline from now until mid-October, I'm afraid I cannot help more in tracking this down.

bzimport added a comment.Via ConduitSep 18 2009, 9:33 PM

Bryan.TongMinh wrote:

The wpSourceType issue was fixed by assuming wpSourceType=file by default. The problem now however is wpEditToken, which is not sent on reuploads (as indicated by Firebug).

Lejonel added a comment.Via ConduitSep 18 2009, 9:36 PM

Maybe the problem described in comment #0 can be temporarily "fixed" by giving autoconfirmed users on Commons the "reupload-shared" right. Admins have this right and they do not seem to have problems with uploading new versions of files. That right should not be needed on Commons. But the error message in comment #0 is the Czech version of [[MediaWiki:Fileexists-shared-forbidden]], which is what users without that right on other projects get when they try to locally upload filenames that exists on Commons.

bzimport added a comment.Via ConduitSep 18 2009, 9:38 PM

Bryan.TongMinh wrote:

(In reply to comment #27)

Maybe the problem described in comment #0 can be temporarily "fixed" by giving
autoconfirmed users on Commons the "reupload-shared" right. Admins have this
right and they do not seem to have problems with uploading new versions of
files. That right should not be needed on Commons. But the error message in
comment #0 is the Czech version of [[MediaWiki:Fileexists-shared-forbidden]],
which is what users without that right on other projects get when they try to
locally upload filenames that exists on Commons.

As described in comment #23, this is a feature, not a bug. However if the previous behaviour was different, we could consider giving reupload-shared to autoconfirmed by default.

Lejonel added a comment.Via ConduitSep 18 2009, 10:32 PM

(In reply to comment #28)

As described in comment #23, this is a feature, not a bug. However if the
previous behaviour was different, we could consider giving reupload-shared to
autoconfirmed by default.

It is definitely a bug on Commons. Autoconfirmed users have always been able to reupload files there, since they have the "reupload" right. The "reupload-shared" right and associated MediaWiki messages should not have any meaning there.
But since the error message is displayed I thought that giving the right to more users may be a temporary workaround for the problem.

There seems to be similar problems on other wikis. Comment #19 is about reuploading a file at itwiki.
If the filename already exists at Commons the behaviour is expected. Only admins should be able to upload the file locally, and the feature works (almost, the error message should display the filename in place of $1, but that would probably be another bug).
But if the filename only exists at itwiki, then previous behaviour was that autoconfirmed users could reupload it. And the new behaviour is a bug similar to what is described in comment #0 on Commons. (The problem described in #1 looks a bit different. And I dont know if it may be related).

Melos added a comment.Via ConduitSep 18 2009, 10:50 PM

(In reply to comment #23)

(In reply to comment #19)
> On itwiki autoconfirmed user can't upload a new file version (see attachment
> for error details), no problem instead with sysop rights.
> Is it related to this bug or it is a separate issue? Thanks (sorry for double
> comment)
>

It is a different issue. I thought this restriction was in place before the new
code as well, but please correct me if I'm wrong: Users can not upload an image
which also exists under the same name as on Commons. Was this the previous
situation as well?

No, IMHO it is a bug. You are talking about "Reupload-shared" right but this is another issue.
I got this error for example when I try to upload new version of [[w:it:File:Pozzallo-Stemma.png]]. It does't exist any file on commons with this name!

bzimport added a comment.Via ConduitSep 18 2009, 11:16 PM

ss755 wrote:

Just to confirm I'm using en.wiki and have been getting the same error as reported in the first comment and by the user on it.wiki. I've just tried uploading a new image on commons too and get exactly the same error.

bzimport added a comment.Via ConduitSep 19 2009, 9:03 AM

Bryan.TongMinh wrote:

reupload-shared problem fixed in r56631, waiting for shell to sync.

bzimport added a comment.Via ConduitSep 20 2009, 7:17 AM

chandrew1119 wrote:

I cannot upload file's new version, It still does'nt work.

bzimport added a comment.Via ConduitSep 20 2009, 11:14 AM

francois.alloing wrote:

Same thing for me. On Commons I still cannot upload a new version of a file I created.

bzimport added a comment.Via ConduitSep 20 2009, 9:19 PM

dancraggs wrote:

We still don't have a fix for this? What's taking so long to correct this severe error? Are we just waiting for a backend sync again?

bzimport added a comment.Via ConduitSep 20 2009, 9:23 PM

Bryan.TongMinh wrote:

(In reply to comment #35)

We still don't have a fix for this? What's taking so long to correct this
severe error? Are we just waiting for a backend sync again?

There is a fix, see #32, but we are waiting for somebody to sync this fix to Wikimedia servers.

bzimport added a comment.Via ConduitSep 20 2009, 9:26 PM

dancraggs wrote:

(In reply to comment #36)

(In reply to comment #35)
> We still don't have a fix for this? What's taking so long to correct this
> severe error? Are we just waiting for a backend sync again?
>

There is a fix, see #32, but we are waiting for somebody to sync this fix to
Wikimedia servers.

So who can we prod to do this? ;-)

Platonides added a comment.Via ConduitSep 20 2009, 11:04 PM

*** Bug 20750 has been marked as a duplicate of this bug. ***

werdna added a comment.Via ConduitSep 21 2009, 12:13 PM

Had a look, looks like it needs r56631, and possibly r56639 and r56640 to be merged.

Want to clarify this with Bryan before pushing live.

bzimport added a comment.Via ConduitSep 21 2009, 7:11 PM

tetromino wrote:

Guys, are you planning to fix this any time soon?

This bug has been affecting most wikipedia and commons users (admins don't count, they are a tiny minority) for over 4 days. On ruwiki, I have seen users being forced to resort to ridiculous workarounds (like uploading a file under a new filename and marking the old one as {{Db-duplicate}}, and thus losing all revision history) to upload new versions of their files.

Catrope added a comment.Via ConduitSep 21 2009, 7:14 PM

(In reply to comment #40)

Guys, are you planning to fix this any time soon?

This bug has been affecting most wikipedia and commons users (admins don't
count, they are a tiny minority) for over 4 days. On ruwiki, I have seen users
being forced to resort to ridiculous workarounds (like uploading a file under a
new filename and marking the old one as {{Db-duplicate}}, and thus losing all
revision history) to upload new versions of their files.

Yes, we're planning to fix this today (hopefully); Andrew's comment #39 illustrates this. The problems is that while we have a fix, we're looking for Bryan (the author of the fix) because we need him to clarify some things.

werdna added a comment.Via ConduitSep 21 2009, 9:28 PM

Fix deployed.

bzimport added a comment.Via ConduitSep 25 2009, 6:04 PM

pku wrote:

The problem is not really resolved, http://toolserver.org/~magnus/flickr2commons.php still does not work.

brion added a comment.Via ConduitSep 25 2009, 6:06 PM

Pieter, that'll be a separate issue; can you open a separate bug about it, and we'll poke Magnus to help debug it?

bzimport added a comment.Via ConduitSep 25 2009, 10:11 PM

pku wrote:

Sorry, I am not at home here on bugzilla. I only registered an account last week to vote for this upload bug. Ok then, I will try to open a separate thing.

Platonides added a comment.Via ConduitSep 25 2009, 10:13 PM

Pieter, that should probably be opened at jira https://jira.toolserver.org/ against the tool (then magnus could take it back against mediawiki).

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:47 AM
Gilles moved this task to Closed on the Multimedia workboard.Via WebDec 4 2014, 10:49 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.