ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Allow to put attachments into a directory hierarchy in the filesystem (Feature #314)


Added by Holger Just at 2011-04-04 11:40 am. Updated at 2011-04-06 10:08 pm.


Status:Open Start date:2011-04-04
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:File uploads
Target version:-
Remote issue URL: Affected version:

Description

If a ChiliProject installation uses many attachments, they are all uploaded into one single directory. Common filesystems (like ext3) start to get increasingly inefficient with many files in a single directory.

I propose to allow to shard the attachment namespace into different directories. This could be done by shading on the first (few?) characters of the filename, or by the upload date or attachment id (and thus allowing say 200 files in one directory and then starting a new one)


History

Updated by Holger Just at 2011-04-04 11:43 am

Oh, and there should be a usable API to override the sharding algorithm from a plugin.

Updated by Eric Davis at 2011-04-06 10:08 pm

+1 first few characters

+1 upload date, looks like the filename gets that prefix already (DateTime.now.strftime("%y%m%d%H%M%S"))

-1 attachment id. Since each upload is an attachment you'd end up with one file per directory and have the same issue as before but with a ton of directories.

-1 on container id (e.g. linked issue/project/wiki). If we allow editing an attachment in the future, we'd have to re-link them too. (e.g. move upload from a project to a version)

I think if we group by update date that would be the best default. That way people can archive old uploaded if they want too. (maybe just group by %y/%m/%d or %y%m%d)

Also available in: Atom PDF