Manual talk:$wgHashedUploadDirectory

changing an existing configuration
You will receive following error (MW 1.9.2)

 Warning: imagecreatefrompng(E:\Programme\xampp\htdocs\w/images/1_GrafikTest_01_1024.png) [function.imagecreatefrompng]: failed to open stream: No such file or directory in E:\Programme\xampp\htdocs\w\includes\Image.php on line 1266

Warning: imagecopyresampled: supplied argument is not a valid Image resource in E:\Programme\xampp\htdocs\w\includes\Image.php on line 1274

Fatal error: imagepng [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in E:\Programme\xampp\htdocs\w\includes\Image.php on line 1275

Migration from $wgHashedUploadDirectory = false to $wgHashedUploadDirectory = true // Moving to the system
Does anyone have a script which runs through the uploads dir and files existing images into this new structure? I have way too many images just in the image folder, but there does not seem to be a migration path. --ThePlaz 07:14, 10 March 2010 (UTC)

Script
Thanx to Platonides !!mediawiki-l/2010-April/033779.html Make a backup archive of the images folder first ! Btw. this script should not touch subdirectories you may use for some extension scripts.

Changes / manual work:

mkdir($folder, 0755, true); chown($folder, "www-data"); chgrp($folder, "www-data"); chown www-data:www-data *
 * You may have to modify permissions, e.g.
 * then manually fix the owner of the top level directories
 * Then get rid of the contents of the thumb subdirectory, except "archive" ? (thumbs subdirectories will be automatically re-generated when users access pages)
 * Finally make sure that the cashes you use are emptied, e.g. "TRUNCATE TABLE objectcache;" in the MySQL database and kill the files in the file-cache subdirectory.

What is the virtue of using hashed upload directories
The one-liner, "If true, use the /a/ab/foo.png directory structure." does not describe any virtues.

Given that this decision is best made before any images are uploaded to a newly created wiki, I think that this article should describe the pros and cons of specifying

Newcomers to MediaWiki installation and configuration will then be able to make a decision appropriate to the expected size and traffic for a new wiki. Najevi 17:40, 26 September 2010 (UTC)
 * Performance is the reason. Now the article also tells this:
 * ''This is used to avoid having too many files in one folder because some filesystems don't perform well with large numbers of files in one folder.
 * --88.130.88.189 16:11, 19 December 2014 (UTC)
 * Which file systems? NTFS, or ext4 too? MW131tester (talk) 10:43, 8 February 2019 (UTC)

Why "f/f8/" not "f/8/"?
Why is the second folder repeating the first character? --93.184.128.22 10:18, 26 April 2016 (UTC)
 * I don't think there is a technical reason for repating the first letter. I guess this is a design decision - and maybe not the worst one. It has the advantage that from a folder in the second level, you can directly tell in which first-level folder you are. E.g. if you are seeing folders like "f8", "f9" and so on, then you know that on the first level, you are inside the "f" folder. This would not be possible, if the folders only had the second sign of the hash value as their name. That way you could easily confuse different folders as it would not be so obvious inside which first-level folder you currently are. The current naming scheme prevents this source of confusion. --2001:16B8:10D8:FE00:3505:60D3:E052:249D 10:59, 28 January 2018 (UTC)