Opened 17 years ago

Closed 16 years ago

Last modified 13 years ago

#5485 closed (wontfix)

Changing repetitive uploaded files from underscores to numbers

Reported by: emperorcezar Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Keywords: fs-rf-docs
Cc: emperorcezar@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently The filefield adds an underscore if you upload to a file that already exists. This leads to files like file_.txt
This is annoying. The patch sets the system to create files file.txt, file_2.txt ..... file_99.txt etc.

Attachments (1)

base.py.diff (1.5 KB ) - added by emperorcezar 17 years ago.

Download all attachments as: .zip

Change History (15)

by emperorcezar, 17 years ago

Attachment: base.py.diff added

comment:1 by deepak <deep.thukral@…>, 17 years ago

Component: UncategorizedDatabase wrapper
Has patch: set
Needs tests: set
Triage Stage: UnreviewedDesign decision needed

What is the problem with underscore? Its simple, fast and effective.

comment:2 by James Bennett, 17 years ago

Resolution: wontfix
Status: newclosed

Every solution to this problem will annoy someone; if we switch it to numbers, someone who liked the underscores will complain. Since this is essentially arbitrary, and since Django's already picked a solution, I'm going to wontfix this.

comment:3 by emperorcezar, 17 years ago

Resolution: wontfix
Status: closedreopened

The issue is two-fold. First, some systems have a character limit on filenames (255 on BSD if I remember). Second, it's difficult to manually and visually distinguish between underscored files. Put 30 avatar_.jpg files like avatar.jpg avatar_.jpg. Then when one has to delete the correct one by hand for some reason, a mistake becomes extremely easy vs deleting avatar_15.jpg Also, at what point will the database max out on the file length? It is my opinion that the repeated underscore may be simple and fast, but they are by far not effective when an application has to scale.

comment:4 by Jacob, 16 years ago

Triage Stage: Design decision neededAccepted

comment:5 by Marty Alchin, 16 years ago

Keywords: fs-rf added

comment:6 by Marty Alchin, 16 years ago

Keywords: fs-rf-docs added; fs-rf removed

comment:7 by Marty Alchin, 16 years ago

milestone: 1.0 beta

comment:8 by David Dahl, 16 years ago

Owner: changed from nobody to David Dahl
Status: reopenednew

I will write some tests for this patch

comment:9 by David Dahl, 16 years ago

With Trunk SVN: Last Changed Rev: 7950

I cannot apply this patch to attempt writing tests:

patch: Only garbage was found in the patch input.

Very strange.

comment:10 by Marty Alchin, 16 years ago

With #5361, this behavior will be made quite easy, and its documentation will explain how to do it. In fact, there's already a test on that patch making sure that Trac-style file numbering (filename.3.txt, etc) works just fine. I've left this ticket open so we can keep of everything that #5361 is looking to address, but any fixes to this will be applied in that ticket instead.

The fs-rf-docs keyword here means that the docs on #5361 will explain how to do it, but it won't be enabled by default. There's certainly a case for changing it, and it would be backwards-compatible, since existing filenames are already stored in the database, but at the moment I'm not planning to change the default behavior.

comment:11 by David Dahl, 16 years ago

Owner: changed from David Dahl to nobody

Ok, cool thanks for the info.

comment:12 by anonymous, 16 years ago

Cc: emperorcezar@… added

comment:13 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

File storage is in as of [8244], so I'm marking this as wontfix -- as Marty says, it's very easy to write a custom file storage backend that works exactly how you like it.

comment:14 by Jacob, 13 years ago

milestone: 1.0 beta

Milestone 1.0 beta deleted

Note: See TracTickets for help on using tickets.
Back to Top