#9893: Filename + path length greater than 100 truncated on database insertion 
in
Core.Storage
-------------------------------------+--------------------------------------
          Reporter:  Refefer         |         Owner:  nobody           
            Status:  new             |     Milestone:  1.1              
         Component:  Core framework  |       Version:  SVN              
        Resolution:                  |      Keywords:  storage, filename
             Stage:  Accepted        |     Has_patch:  1                
        Needs_docs:  0               |   Needs_tests:  0                
Needs_better_patch:  0               |  
-------------------------------------+--------------------------------------
Comment (by akaihola):

 Issues to consider:

 Smart truncation can't be done in the storage object
 since it doesn't know about the `max_length=` of the `FileField`.
 The maximum length can be set to a different value than 100 in the model.

 One possibility is to extend the signature of
 `Storage.get_valid_name()` and `.get_available_name()` to accept
 a maximum file name length argument, but I assume that's sub-optimal.

 Truncation should avoid collisions with existing file names.
 Simply shortening the file name isn't sufficient,
 but something similar to what VFAT did with its `FILENA~1.EXT`
 8.3-character filename representations should be used.
 `Storage.exists()` can be called to check for collisions.

 The `upload_to=` kwarg of `FileField` can be either
  * a string specifying the target directory, or
  * a callable which replaces `FileField.generate_filename`
    and returns the path to the file to be saved.
 In case of a callable, do we leave length checking as responsibility of
 the callable,
 or should we prepare to truncate the generated path?

 Truncation could be done in `FileField.generate_filename()`,
 but how to ensure the generated filename is still valid for the storage?
 This is an issue if a numbering scheme must be used to avoid file name
 collisions.

 What if the directory is already too long without the actual file name?
 This shouldn't be an issue when `upload_to=` is a string,
 but a callable might generate a long path if not coded carefully.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/9893#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to