Fixed #10121: Restored code lost in r9766 that prevented overwriting an already-set blank=True FileField with blank. This would happen, for instance, in the admin if an object with a FileField was edited/saved but the file not re-uploaded, resulting in the association to the previously-uploaded file being lost. Adding the ability to re-blank FileFields when they are once set is the subject of a different ticket (#7048), for now the pre-9766 behavior here has just been restored in order to avoid unexpected data loss. Thanks to Alex for help in understanding how to fix this without un-doing the intent of r9766.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@9840 bcc190cf-cafb-0310-a4f2-bffc1f526a37

django/db/models/fields/files.py

@@ -213,6 +213,10 @@ class FileField(Field):
     def generate_filename(self, instance, filename):
         return os.path.join(self.get_directory_name(), self.get_filename(filename))
 
+    def save_form_data(self, instance, data):
+        if data:
+            setattr(instance, self.name, data)
+
     def formfield(self, **kwargs):
         defaults = {'form_class': forms.FileField}
         # If a file has been provided previously, then the form doesn't require

tests/modeltests/model_forms/models.py

@@ -1030,6 +1030,18 @@ True
 >>> instance.file
 <FieldFile: tests/test3.txt>
 
+# Instance can be edited w/out re-uploading the file and existing file should be preserved.
+
+>>> f = TextFileForm(data={'description': u'New Description'}, instance=instance)
+>>> f.fields['file'].required = False
+>>> f.is_valid()
+True
+>>> instance = f.save()
+>>> instance.description
+u'New Description'
+>>> instance.file
+<FieldFile: tests/test3.txt>
+
 # Delete the current file since this is not done by Django.
 >>> instance.file.delete()
 >>> instance.delete()