View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003172 | Composr | core | public | 2017-03-31 13:51 | 2018-04-11 05:26 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003172: Deep upload directory structures | ||||
| Description | Currently all uploads of a certain type are kept in a single directory. This is slow to navigate using file browsers (e.g. FTP). It is also a bit disorganised for people manually administration their content directories, especially for galleries. It shouldn't perform any performance degradation within Composr though, as B-Tree or hashmap indexing exists in all modern filesystems that may be in use (HFS+, NTFS, ext3, ext4, Btrfs). Here are upload directories that should be split up by category hierarchy... downloads gallery images & thumbs gallery videos & thumbs catalogues repimages Here are upload directories that should be split up alphabetically, using an infinite tree growth algorithm... attachments & thumbs auto_thumbs cns_avatars cns_photos & thumbs It will be technically difficult to implement this because directory positions would need changing when entries are moved between categories, and on moving you can't do a naive move because of the possibility of a filename conflict in the new destination - so it needs to do a re-check for an adjusted non-conflicting filename. It should also be optional, so people can temporarily disable it if it is buggy. For the case of infinite tree growth, files would need to be moved around each time a new tree growth happens. | ||||
| Additional Information | References... http://serverfault.com/questions/98235/how-many-files-in-a-directory-is-too-many-downloading-data-from-net https://compo.sr/forum/topicview/browse/designing/two-type-of-galleries.htm?post_id=2118&topic_id=398×tamp=1490957280&redirected=1&redirected=1 | ||||
| Tags | Type: Cross-cutting feature, Type: Performance, Type: Usability (major) | ||||
| Time estimation (hours) | 24 | ||||
| Sponsorship open | |||||
|
|
I've now implemented this, except for the 2nd half (infinite tree growth algorithm). I don't think infinite tree growth algorithm is really useful. After talking with a user I have found the main issue for them is when they're manually working in the filesystem and losing stuff due to too many files (especially if they upload multiple files with the same name and they have to get auto-renamed). Infinite tree growth algorithm would actually make it even harder for them. My implementation is quite sophisticated. You can turn deep mode on and off, and there's a cleanup tool to move everything back around and keep it clean. It's pretty similar to how iTunes can be configured to automatically maintain a deep directory structure for your music. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-03-31 13:51 | Chris Graham | New Issue | |
| 2017-03-31 13:51 | Chris Graham | Tag Attached: Type: Cross-cutting feature | |
| 2017-03-31 13:51 | Chris Graham | Tag Attached: Type: Performance | |
| 2017-05-01 15:42 | Chris Graham | Tag Attached: Type: Usability (major) | |
| 2018-04-11 05:26 | Chris Graham | Note Added: 0005661 | |
| 2018-04-11 05:26 | Chris Graham | Status | non-assigned => resolved |
| 2018-04-11 05:26 | Chris Graham | Resolution | open => fixed |
| 2018-04-11 05:26 | Chris Graham | Assigned To | => Chris Graham |
