組織與管理/目錄結構
目錄結構
擁有數據卻無法在需要的時候找到它，那它是文件還是垃圾？
組織所擁有的數據非常簡單，我每次都設計出近乎於完美的目錄結構。組織內容的方式是沒有盡頭的，我們總能找到更適合自己的方案，也不存在某個標準答案，因為除技術外，它更多受體量及時間的影響，例如：
- 「動漫」原只是位於「圖文影音」目錄中的一份子，而現在它自成頂級目錄，因為數據量的計算單位由GB提升至了TB。而沒有繼續增加收藏的原因並非收集完了所有喜愛的作品，只是剩餘作品的綜合權重不足以無限制的「侵吞」我有限的硬盤空間。當我用於存儲資源的空間從數TiB提升至如今的100TiB，這樣的抉擇就沒斷過。
- 「網站鏡像」原只是一個微不足道的項目，存放於微不足道的目錄，直到時間這無形的大手使我收藏的站點不斷傳來無法訪問的噩耗，我失去了閱讀曾喜愛文章的機會，它便魚躍龍門，成為了核心項目；曾經發生了一些事件，我按照我的感受將對應的資源放置於「Ａ」目錄，可時間的大手抹去了我的感情，以至於我需要時才發覺我無法回憶它的存放位置。
自以為完美結構滿足的是當下及可預見未來的需求，時間線被拉長它會失效，我們無法預見到的事發生它亦會失效，我們需要不斷的修改結構以適應最新的需求。因此，組織與管理的方式沒有盡頭，有的只是體量增長後的沒必要：當動漫資源單獨佔據一塊16TB硬盤而不參與目錄結構設計時，我自不必在意；為能力計的妥協：設計出符合需求的複雜結構並不難，難得是遵循這套標準，相較而言，從便利上讓步轉而採用傳統方案才是優解。
不可否認的是，我們的眼光大都近似於夢中制定的精密計劃和說出的驚天語錄，一旦醒來再回味就會發出「wtf？」的疑惑。我們只能在某種程度上對其規範化使資源更便於處理；通過參閱更多信息延長可預見未來的範圍、通過性質分離減少情感對歸類的誤判；利用簡易工具及低技術方案在沒有過多壓力的情況下提升處理效率。這也正是本文計劃做的。
足夠的樣本才能訓練出合適的結構。樣本太少時，難免很多情況無法顧及到，經過推演出的結果又不一定符合需求，有切實的足夠多的樣本才是重點。總而言之，設計理念圍繞兩個關鍵詞展開：性質分離、少結構層次
除了文件類型及題材外，我們要從更深遠的視角考慮文件結構的設計。
- 例如備份的角度，區分個人文件、網絡收集文件、可復刻的文件，對於獨一無二的，我們在備份時應更謹慎，而對於可復刻的，我們應當根據來源及復刻難易度調整備份策略，是記錄來源、記錄文件名(跑目錄樹)、還是也需要進行備份。
- 例如重要性的角度，區分自產文件、外部文件、珍稀文件，明確哪些內容是需要我們重點呵護的，並做好性質分離，使它們不過分交叉以至於影響後續備份或整理。
- 例如文件體量的角度、剝離了感性後的角度(或者試着冷卻一段時間再進行歸類)。
從而抵消現行情緒狀態對理性的影響，可以最大程度的避免未來找不到文件時發生「當時我為啥這樣設計來着？」的窘狀。
簡潔高層目錄，精簡目錄深度，追溯一個文件的路徑越短越好、同級目錄越少越好，越精簡越方便定義及維護。
當你是囤積大戶時，不要用 媒體資源 囊括所有的圖文影音，尤其是它們各自能佔據一塊硬盤以上時，讓其各自為戰。可以按照類型劃分文件，但不要過於細分不熟悉領域，而後看自己經常訪問什麼， 並將之目錄層級提升（對於具有時效性的，建議軟連結/符號連結）。
這一行為的根本是避免維護目錄嵌套及設計邏輯帶來的額外記憶負擔，你設計的越複雜，需要記憶的內容就越多，你註定無法每天都與之打交道，隨着時間的推移總有被遺漏的那天，一旦發生便是災難，你將對你設計的目錄感到陌生，就像你曾滿腔熱血的為標籤設計受控詞彙表但最終一切歸於混亂一樣。長時間不用記憶力會衰退，陌生的感覺可以摧毀此前消耗的所有心血，當然更可能的是在這個過程中你發現其實你只頻繁使用某個或某幾個文件夾，而其他大多數內容都陷入了沉寂路過都不帶看一眼的。
打倒複雜設計，讓需求主導結構。
稟着以上兩種理念就能構建出完美方案了嗎？不能，未來是不可預見的，我們只能不斷的改進以適合未來自己的需求，我們能做的只有儘量做好性質分離和結構層次的把控，從而減少情緒化對客觀性影響。
時間能改變結構權重，當下或許我側重於web檔案，因此它是頂級結構，但如果未來我傾向於收集電影呢？電影將由二三級升為頂級結構，這是很好理解的，但難以理解與預見的是隨着時間的推移，整個系統近乎於重構的改動。但那是未來的我需要面對的問題，皆是我應該為擁有更大體量的收藏庫感到榮幸。
總而言之，這是我的部分目錄設計參考：
- 核心文件（現行自產文件）
- 站點存檔
- 資料存檔
- ……
文件註釋
主要針對於來自網絡中的文件。
對於數據收藏癖而言，絕大多數文件都來自於網絡，但不是所有內容都來自於標準渠道。
| 標準渠道 | 非標準渠道 | |
|---|---|---|
| 一般文件 | 無需註釋 | 需要註釋 |
| 非標準文件 | 視情況而定 | 需要註釋 |
- 標準渠道：正規流媒體平台(tidla/qobuz/youtube)或命名嚴謹的發佈組(bt/pt)、打包或分發採取統一結構的組織。
- 非標準渠道：不具備通用性，沒有明確的結構，需要記錄否則便無法輕易找到文件源頭(含同質量替代品)的。
- 一般文件：例如出版媒體等具有規範定義的。
- 非標準文件：個人組織或分發的內容，不具備通用性，沒有明確的渠道可以追溯；對一般文件進行了修改導致丟失從標準渠道追溯文件的信息時(包括自己修改文件名)。
這是大概的思路，簡單來說，便是一眼知道來源能快速複製同樣的文件或上位替代品的，便沒必要註釋來源，反之則順手記錄（確實沒有來源的，例如自製或自己用工具下載的除外）。
我不以標籤的形式註釋，而是粗暴的在對應目錄內添加一個文本文件：.info 用於記錄關於該文件的信息，如果要用於記錄來源則拓展命名為：.info src 。
註釋文本不知可以用於記錄來源，更主要的是記錄有關文件的信息，它是幹什麼的、什麼時候下載的、需要補充哪些內容。
您可以根據需要自行拓展命名包括但不限於up表示這是持續更新項目、xxx表示來自某個經常出現的數據源……
但我個人只使用.info、.info src兩種形式，因為我始終遵循精簡原則而不節外生枝使系統變得臃腫。
對於文件類型和更新時間，我可以用目錄及目錄名處理，可以寫在.info內，至於我如何知道它是會持續更新的，我只能說依靠記憶，因為我儘管是數據收藏癖，但我很少收集我並不知曉的內容。如果您是隨機收集可以考慮用標籤文件管理器解決。
對於大型項目，尤其是我自己維護和填充的例如後末日生存文檔集、ACG相關（例如BDMV、galgame）我直接在項目文件夾內寫統計表，excel、記事本、.md無論什麼，只要能達成目的即可。
不論何時，標記只是輔助，我絕對不會讓其凌駕於數據之上。
文件處理
結構變動或處理仍舊有用的文件時請評判行為的三項特徵：是否可逆，是否可追溯，是否易於尋址。並酌情處理（參考組織與管理/圖文影音#文件結構）。