On Mon, Apr 6, 2009 at 1:16 PM, Karen Tracey <kmtra...@gmail.com> wrote: > We cannot know for sure what the file name is until it is saved to disk, as > the save operation may tack on underscores when handling race conditions. > Thus we cannot delay file save to a field pre_save routine and report the > guaranteed correct file name in a pre_save signal handler, since the latter > runs before the former.
Yes, very true. I wrote my reply in a hurry to get you some more information, and didn't really think all the way through that one. > I feel like I'm going around in circles thinking about this one -- is there > a way out that someone else sees that I'm blind to? Welcome to my world! :( I spent a long time on issues like this prior to getting the new file storage system in place at first, and apparently skipped much of that step when doing r9766. At this point, I think the most useful approach is to take a step back and just look at the high-level options we have available. Trying to determine the name in advance is a no-go, because that would just make the existing known race conditions much more prominent. I see two options left: 1. Write something to disk (maybe the whole file, as it was before, maybe just a placeholder, as the _save() does now) when the file is first assigned, so that we have a full, proper filename early on. Then, if the model doesn't get saved, somehow roll that back so we don't leave stuff lingering on the filesystem. This is currently something of a "then some magic happens" approach, since I'm not yet sure if there's a reasonable, reliable way to roll back a file save. But I'd like to keep an open mind, so there it is. This would also be preferable if we can detect transaction rollbacks, because there is also #6456 to consider. 2. Save the file all at once, as soon as possible, and blatantly document this behavior when model validation goes in. Then, if people need to validate a model that has a file on it, they have two options: validate the model *before* saving the file to it, so the model is known to be valid and can all be saved at once, or (if they need to validate something in the file, such as its name or contents), add their own code to delete the file if validation fails. Or, I suppose a third option is to ignore the lingering files until they suck up too much space, requiring a manual purge. I obviously hate to go with number 2, but if we can't come up with something solid, I think it's the better approach, at least for now. Documenting unfortunate behavior is certainly preferable to coding even more unfortunate behavior. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
