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.

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?!

CC'ing Michael, probably new-upload regression?

mdale wrote:

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

ss755 wrote:

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

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.

Steps for me to reproduce the has problem:

1. go to http://en.wikipedia.org/wiki/File:Long_leg_hair.jpg

2. save the image to local disk

3. hit "Upload a new version of this image"

4. Select the saved file from disk

5. *uncheck* 'Ignore warnings'

6. Click through the duplicate file warning

7. 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.

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.

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 ?

Bryan.TongMinh wrote:

Now it does. Please try again.

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.

Bryan.TongMinh wrote:

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

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.

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.

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.

mbzmbz77 wrote:

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

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

2. I go to the file page.

3. As there is no file, I've got this message : "No file by this name exists, but you can upload it."

4. I click on upload it.

5. I arrived on the classical commons upload form.

6. I click on Browse.

7. I select the file.

8. I click on Upload file.

9. I go back to step 5 without error message or warning or upload of the file.

Created attachment 6562
Upload new version

Attached:

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)

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).

mycae wrote:

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

verszil wrote:

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

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?

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.

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.

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).

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.

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.

(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).

(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!

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.

Bryan.TongMinh wrote:

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

chandrew1119 wrote:

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

francois.alloing wrote:

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

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?

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.

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? ;-)

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

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.

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.

(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.

Fix deployed.

pku wrote:

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

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

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.

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