On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi all, > > I had a previous post on this issue which I did not get very many > answers to. In particular, I did not have many responses those who may > be more directly involved with the development of this great Framework > (or maybe more appropriately the Admin extension of it? which is such a > feature that for all practical purposes it may well be seen as core to > the Framework.) > > The default behaviour is for Admin not to overwrite a file with a newer > one posted with the same name, i.e. if I upload a file called ycoci.jpg > to a folder which contains an older version of the same file, the newer > one will be renamed wthin an underscore,ycoci_.jpg. > > I would like to know why this is handled in this way, as find it very > unintuitive (There many well be a very valid reason for handling things > in this way? However, it seems to me that the natural thing to do is > to rename the older file with the underscore then delete it, before > posting the newer file with the original name). > > I have developed a very workable web project with Django 0.91, but this > behaviour is causing me real grief, as I now have loads of files on > disc that are not being used, which is a huge waste of disc space and > one part of my project depends on files preserving their names. > I agree - mostly. If the new file is to replace the old file, then why should the link to the file constantly change? Consider this example: I have a PDF document called example.pdf. On occasion, I may need to make a edit or correction to this document. However, I still want to point my users to example.pdf, not example_.pdf or example__.pdf. The current behavior doesn't seem to fit the never-changing-URLs philosophy.
To compound the situation, suppose example.pdf is an attachment to a world editable wiki page where anyone could upload an updated version of the pdf. Just as the wiki page may have built in history to undue malicious changes to the page, I would want that same functionality for the attachments. It would then make sense to have older versions of the file renamed with a timestamp (i.e.: example_20060530121302.pdf, or example_20060402.pdf) while the newest version maintains the original name (example.pdf). If someone tries to maliciously overwrite the file, then the older (good) version could simply be renamed to remove the timestamp. However, unlike Y-coci suggests, I would not want the older version to be deleted by default. If the older version is the one being renamed either with a underscore, a timestamp or some other means (not the current behavior) then a simple cron job could be run on occasion to clean out older versions leaving the most recent in tact and keeping the waste of disk space to a minimum. I would propose an additional setting to address this. Perhaps something like DUPLICATE_FILE_SUFIX = '_'. One could then set it to datetime.datetime.now() or anything else s/he pleases. Of course, the code would still need to be altered to rename the old file rather than the new one. > I would be grateful for any suggestions as to how I can get around this > limitation. You could try to override django's default behavior. The code can be found at django/db/models/base.py on about line 300 in the function _save_FIELD_file(). Rather than altering the core code, it may be possible to redefine that function in your model much as you would the save() function. Of course, I haven't tried it myself, but don't see why it wouldn't work. If you get some code that works, post it to the wiki as your not the first person to request that. On further contemplation and after reviewing the code in _save_FIELD_file(), it occured to me that the current implementation is for a simpler use case than I was first considering. Using the wiki senario again: Let's say I have an attachment to Page1 named example.pdf. Another user creates Page2 and adds an attachment example.pdf. The new file should not overwrite the old file so the underscore is appended making Page2's attachement example_.pdf. If you want something more complex you need to add it yourself, which shouldn't be to diffucult. Although, I will say having the DUPLICATE_FILE_SUFIX setting by default would be nice. > > Thanks and Best, > > Y-coci > > > > > -- ---- Waylan Limberg [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
