FileField has max_length=100 but filestorage may return something way longer

[Harro]

So to keep al the uploaded files a bit sorted they all get added to specific folders. MEDIA_ROOT + 'user/10/profile/files/'

Then the user comes along and uploads a file with a very long name then the FileStorage stores the file just fine, the path get's returned and through the ORM passed to the database backend which might throw an error about the filefield exceeting 100 characters.

Mysql for instance just trims the value without complaining, thus storing an incomplete path.
Postgres will throw an exception which the user gets as a 500 error and we get an e-mail that we have to fix it.

Solutions:

• Don't store the path in the database, keep that in the upload_to for the model, downside is that if it changes all the already uploaded files will not be found.
• FileStorage should make sure the path doesn't exceed max_length, downside is that if the path part is 99 characters long the filename gets 1 character. (Or 120 and -20 :P)
• FileField should validate the length of the path returned and give the user the error that they should shorted their filename to max X characters (X being dependand on the path prefix)

Which is best, I don't know, maybe a combination of those things.

[Paul McMillan]

This is definitely a bug as-is. Something in this chain needs to validate the length before it hits the DB.

My preference would be to pass the max_length parameter along to the file backend and let it produce (however it can) a filename that will fit that. It already manipulates the name in case of duplicate files, so trimming if necessary shouldn't be much more work.

I think we would prefer to mangle filenames over throwing an error back at the user after they've finished uploading the file.

[Ramiro Morales]

Duplicate of #11027.

[Russell Keith-Magee]

In [15540]:

Fixed #15247 -- Ensured that if a SingleObject view defines get_object but not get_queryset, the ModelFormMixin doesn't fail. Thanks to Sergey N. Belinsky for the report and test case.

[Russell Keith-Magee]

Oops - fat fingers. That commit message should be for #15274.

[Carl Meyer]

Reopening just to re-close as duplicate of #11027. Sorry for the noise, but it's confusing for this to be labeled "fixed" in big letters at the top of the Trac page, when it is not fixed.