Last modified: 2009-09-25 22:26:32 UTC
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
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.
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?
I am also having trouble reproducing the error locally or on commons.
I just tried after reporting it wouldn't work earlier and it's still giving me the same error.
...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.
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.
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 ?
Now it does. Please try again.
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.
Flickr Upload Bot is a toolserver service and not a MediaWiki function.
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.
(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.
(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.
It still does not work in Commons. I cannot overwrite my file with a new version.
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 [details] Upload new version
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)
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).
CCing -- I have seen this a few times now.
It is confirmed that on Commons, it's the same bug. Admins could upload a new version, other users can't.
(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?
(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.
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.
(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!
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.
reupload-shared problem fixed in r56631, waiting for shell to sync.
I cannot upload file's new version, It still does'nt work.
Same thing for me. On Commons I still cannot upload a new version of a file I created.
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?
(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.
(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.
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.
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?
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).
