Last modified: 2014-04-22 05:47:49 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 363 - (optionally) store uploads in database blobs
(optionally) store uploads in database blobs
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 5406 (view as bug list)
Depends on:
Blocks: 362
  Show dependency treegraph
 
Reported: 2004-09-03 07:37 UTC by Brion Vibber
Modified: 2014-04-22 05:47 UTC (History)
10 users (show)

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


Attachments

Description Brion Vibber 2004-09-03 07:37:26 UTC
Although there are good reasons to use the filesystem for uploaded files, there are also problems with it in 
some situations:

* Security -- world-writable directories on multi-user hosts
* Security -- dangerous filetypes may slip through and execute scripts server-side
* Inconvenient filesystem naming limitations (eg bug 362)
* Stupid configurations -- PHP 'safe mode' and other such things that may make it difficult for some 
installations to have a writable directory tree for uploads

So, it may be useful to optionally provide for storing uploads in BLOBs, as for instance Bugzilla does.

Issues to overcome:
* Maximum file size limited by mysql max packet size [default should be big enough for most purposes]
* Thumbnail generation may need to work via temporary files
Comment 1 Brion Vibber 2006-03-31 08:17:17 UTC
*** Bug 5406 has been marked as a duplicate of this bug. ***
Comment 2 vertigosteve 2006-04-03 18:08:45 UTC
Maybe running a second image database could be given as an option/alternative to
the current form? 
Im sure MySQL can handle this too, but a native XML db would allow for
serialized connection to particular data. That would sort of fit in with the
m:Wikidata proposal.
Comment 3 vertigosteve 2006-04-03 18:10:04 UTC
Now that I think about it, there are probably size issues with any native XML db
too. :)
Comment 4 Brett Berry 2006-04-04 20:44:39 UTC
I am running in a replicated environment, and have MySQL running in a
multi-master mode. We would like to place all uploaded files in the database, so
we will not have to rsynch from location1 to location2, and vice-versa.
Comment 5 Quim Gil 2014-04-15 23:38:04 UTC
No progress since 2006. Is this even a good idea? CCing some Multimedia folks.
Comment 6 Gilles Dubuc 2014-04-17 09:24:58 UTC
It seems like a valid idea, but performance is an unknown and I'm not sure how big the demand for it is. Imho someone who really needs it could build it and share it back upstream. The fact that this hasn't happened yet is probably a sign that people might not need it that badly.

Right now it would seem like spending a significant amount of time building something that only a handful of people might use. And low usage introduces its own issues, such as higher likeliness to break because the foundation wikis aren't running it (and so we're not paying attention to it working properly, beyond unit tests that probably won't have enough coverage).

I definitely agree with giving it Lowest priority...
Comment 7 Aaron Schulz 2014-04-22 05:47:49 UTC
This is pretty much a performance anti-pattern. If someone really wants it they could make a DBFileBackend subclass of FileBackendStore and point $wgLocalFileRepo at it (via the 'backend' field).

(In reply to Brion Vibber from comment #0)
> Although there are good reasons to use the filesystem for uploaded files,
> there are also problems with it in 
> some situations:
> 
> * Security -- world-writable directories on multi-user hosts
> * Security -- dangerous filetypes may slip through and execute scripts
> server-side
> * Inconvenient filesystem naming limitations (eg bug 362)
> * Stupid configurations -- PHP 'safe mode' and other such things that may
> make it difficult for some 
> installations to have a writable directory tree for uploads

Since this report was filed, it is possible to use other backends like S3, Azure, Ceph, Swift, Gluster (Swift compat code). This handles 1 and 3-4.

https://gerrit.wikimedia.org/r/#/c/125573/ is able to handle encoding issues (3). https://gerrit.wikimedia.org/r/#/c/127460/ could also handle long names.

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


Navigation
Links