Remove to-do for lost & found.

Let's see if this inode tracking thing works out, and it might be
an adequate solution to the problem. As long as non-unix filesystems
work reliably and you aren't moving files across partitions.
Hashing is still an idea on the table.
master
voussoir 2020-09-17 17:34:13 -07:00
parent 1af8342202
commit d0b4c20413
1 changed files with 0 additions and 1 deletions

View File

@ -103,7 +103,6 @@ Here is a brief overview of the project to help you learn your way around:
### To do list ### To do list
- Make the wording between "new", "create", "add"; and "remove", "delete" more consistent. - Make the wording between "new", "create", "add"; and "remove", "delete" more consistent.
- User account system, permission levels, private pages. - User account system, permission levels, private pages.
- Some way for the database to re-identify a file that was moved / renamed (lost & found). Maybe file hash of the first few mb is good enough.
- Debate whether the `UserMixin.login` method should accept usernames or I should standardize the usage of IDs only internally. - Debate whether the `UserMixin.login` method should accept usernames or I should standardize the usage of IDs only internally.
- Ability to access user photos by user's ID, not just username. - Ability to access user photos by user's ID, not just username.
- Replace columns like area, ratio, bitrate by using expression indices or views (`width * height` etc). - Replace columns like area, ratio, bitrate by using expression indices or views (`width * height` etc).