Ciao

one millon users, or also we can use hexadecimal notation for ID
and we needed a tree with less levels ( hash_fix_length=5 for 1 millon users)

I see if I can make a draft of the other points

Then, someday, we should be able to abstract all the current file system accesses and create, in a pluggable fashion, all sort of storing systems (file system, local or external DB, other CMS...over mnet...).

That's my point of view. Although it would be easy to store them in DB, just analysing if it's the moment to do that.

Ciao

How about a halfway that caps the number of sub folders to 1000 but remains easy to navigate?

If you took the ID 1123 and replaced the last 3 numbers with zeros, or rounded it down, and created another string with 999 added to it you get '1000' and '1999', concatenate these and add the ID after a slash you'd have '/1000-1999/1123/'. This would be infinitely scalable, and I think a lot easier to nativage 'by eye'.

So a user with an id of 123,456,789 would have a private directory like:

$CFG->dataroot/users/123000000-123999999/123456000-123456999/123456789

and a user with an id of 1,234 a directory like:

$CFG->dataroot/users/0-999999/1000-1999/1234

As the code only uses integer multiplications and divisions, it should be faster than dealing with non-decimal bases, spliting and rejoining strings, etc.

Saludos. Iñaki.

/user/xxxx/yyyy

1000 containing folders 1-1000
2000 containing folders 1001 - 2000
3000 containing folders 2001 - 3000
....

Nicolas, can you do this please?

On reflection I think it's even simpler if the first-level names are the LOWER bound of the 1000 range (first one will be 0)

So, here are the steps:

1) make_user_directory($userid=45678) which will create moodledata/user/45000/45678 and RETURN the full path '45000/45678'
Note use of the 'user' directory which is different from the current "users" directory.
2) Write an upgrade.php routine to:
a) go through the list of directories under the old 'users'
b) for each name, call the new function make_user_directory
c) move the contents of the old directory to the just-created one. You need to use PHP functions for this (not shell) for reliability.
d) put a little README.txt in the old users directory to explain that this is OLD and no longer used. Don't delete it.
3) Identify all the places that save user images (I don't think there's many) and call make_user_directory to find/create the proper directory there before saving.
4) Rewrite user/pix.php to look in the new place. No need to change how it's called though. eg http://moodle.org/user/pix.php/1111/f1.jpg is fine.
5) Test test test
6) Put into 1.8, 1.9 and HEAD

Are't you worried about what happens when moodle.org has 32 million users though

• backup_copy_user_files() in backup
• restore_user_files() in restore (note that this function must accept old backups)

Ciao

With the pix.php file, version 1.16.2.1, that was modified for this bug, it doesn't load any user avatars, all avatars are displayed as the default Moodle smiley face icon. I rolled back to pix.php version 1.16 and the avatars are properly loaded from the moodledata folder.

In all upgrades it has been needed to do it manually.

MDL-10905 is really dangerous for any site generating the "0" folder. And it's implemented in a lot of branches. Need fix ASAP IMO.

Anyway what happens in 1.9/2.0, is the upgrade executed again? What if somebody deletes the picture, would it be copied again from users to user?

Would be a good idea to add one more upgrade block in order to check if the "0" dir has been created and copy missing target users there?

I know it's "only" 1/1000 of users, hehe, but right now their images are in the "limbo", if I'm not wrong.

Just one idea, if effectively, those "0" dirs weren't created and filled for early upgraders.

Ciao