I encountered a problem today when backing up webgui from a samba server to an NTFS volume. Because the uploads folder over time will accumulate folder names like "cC", "cc", and "Cc", it creates an issue when copying the uploads folder to a case-insensitive file system like NTFS (or possibly HFS+ on Mac OS X).

In the case of windows XP, copying "cc" to a folder when "Cc" is already there thinks that you may want to replace the folder...

I am guessing this would also cause issues in the code that is accessing the uploads folder. I do not know if the windows version of webgui works around this somehow, but I would expect it needed to. If indeed there is a workaround shouldn't that also apply to the Linux version to keep things consistent on all platforms?

To me it is more economical to rsync the uploads folder rather than have to tar-gzip it, and download the whole thing every time I backup. 

It appears to me this folder structure aims to reduce the number of files possible in a given folder, to account for possible filesystem limitations (performance or physical limits). What would be the practical impact of dropping mixed-case Object IDs? I think a lowercase ID would be enough to allow sufficient "randomness" of ids by itself.

Or is this a security concern with guessing the ID to access images/etc that one is not allowed to see? If this is the case, a longer, lowercase ID could be used. If DB storage then becomes a concern, then perhaps a numeric system can be used.

 So basically I am just wondering what the motivation for this setup is and wondering if anyone else is interested in improvements in this area...

 A possible solution is to encode the object id when it is passed in to access the uploads folder (or building the URL to an uploaded image). This would avoid the need to change policy on the format of Object IDs, and it would be simple to convert an existing uploads folder to the new format.

 Thoughts?

Bug created.

http://www.plainblack.com/bugs/tracker/uploads-folder-case-sensitive