Last modified: 2010-05-15 15:59:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13210 - Upload a new version of image causes an internal error
Upload a new version of image causes an internal error
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.11.x
Other Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.wikidoc.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-01 15:19 UTC by jacki buros
Modified: 2010-05-15 15:59 UTC (History)
0 users

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


Attachments

Description jacki buros 2008-03-01 15:19:56 UTC
We see an internal error when uploading a new version of certain files, in particular for files that are documents -- word, pdf, ppt, etc. I have not yet noticed the error when replacing an existing file of image type.

An example of one such error message is:

 Could not rename file "public/6/63/Wikidocsearchresults_9.xls" to "public/archive/6/63/20080301151006!Wikidocsearchresults_9.xls".

Though the precise path changes according to the wiki installation that causes the error.

Some comments:
  * we do not have "public" in our path
  * we have set the following in our LocalSettings.php:
         $wgUploadPath       = "$wgScriptPath/images";
         $wgUploadDirectory  = "$IP/images";
  * we do not have php's safe_mode or open_basedir enabled
  * we have no /images/ aliases in apache2 conf files
  * in some cases, the paths which display are quite long and bizarre
  * most other files and images can be replaced without error
  * the files in question can be replaced using ./maintenance/importImage.php --overwrite

Version info is as follows:
    * MediaWiki: 1.11.0
    * PHP: 5.1.2 (apache2handler)
    * MySQL: 5.0.22-Debian_0ubuntu6.06.6-log
Comment 1 Brion Vibber 2008-03-02 21:53:04 UTC
Check the directory and file ownership and privileges. It's fairly likely that you have a mix of different file owners, particularly if you've been using command-line scripts to do file imports.
Comment 2 jacki buros 2008-03-03 03:07:50 UTC
File/directory permissions are the same for all files (system user, 777) though the user is not our apache2 user -- something we did to simplify file synchronization among servers in our cluster. Once I changed this the problem was solved.

For some reason I thought the path was incorrect, but clearly not.

Thanks for your help!

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


Navigation
Links