（一句话）前言 ：暑假事多闲少，填坑一步步来，因为经常需要整理数据，所以想来还是固定一个套路比较好，不是很啰嗦，也没多少新意，里面的一些习惯可能早就传染给了其他人。 - 20160812，深圳
零、适用范围 / Limitation
适用人群：有一定英文使用习惯的计算机用户、学生、以及ICT行业从业人员。
适用范围：数据量在2T以内，存储设备空间充足。
用处：手动减少过量数据冗余，优化存储结构，降低各方面成本。
一、定义 / Definition
1. 目录（directory）是文件（file）的集合（set），在windows下，文件夹（folder）与目录等价；
2. 文件所在的位置（location） + 文件名（filename） = 路径（path）；
3. 当前的文件系统（file system）决定了不存在一个位置允许两个同名文件，即：文件的路径是唯一（unique）的。
二、预设建议 / Proposals
1. 对文件进行简单的唯一存储管理，不使用hard link及symbol link一类的依赖于文件系统的特殊功能（specialized feature）；
2. 目录嵌套一般不超过7层，最多九层，其他情况用压缩包解决；允许例外；
3. 不严格限制最底层目录下的文件数，建议维持在24项以内。如有例外，则其上层目录的项数同样须控制在24项以内，超过60的情况建议时序归档；
4. 单个分类集合的最大文件数量维持在3600/4200/6144为宜，适时使用压缩包代替零散文件簇以提高检索效率。
注：简单的唯一存储管理允许在磁盘空间富余的情况存在一定数量的冗余文件，方便快速调用和备份。
三、命名法 / rules of naming
0. 不修改已知文件的原扩展名；英文名可以忽略大小写和复数形式要求，中文不区分的地得；除特殊情况外优先小写，总体以美观方便易识别为主；
1. 文件的备注信息使用大括号{}，文件夹使用方括号[]，文件夹内的备注信息允许同样使用大括号；
2. 井号（shift+3 #）表示层级提升，下划线（_）仅在前缀时表示类别区分，两者在适当情况下可以混用。不需要存在同时使用两个符号的情况；
3. 升记号（shift+6 ^）表示优先级提升，感叹号（shift+1 !）仅在少数情况下表示最高优先级；感叹号允许最多三次连用；
4. at记号（@）用于可选的关联信息备注，and符号（&）表示先前有存档过的冗余数据；
5. 百分号（%）表示未知内容，波浪号（~）表示不重要，全角问号（？）表示不确定；建议用文字描述替代此类符号连用；
6. 下划线（半角）、加号（+）与减号（-）同为连字符，半角句点（.）和反引号（`）用作层级连接表示；
7. 允许中英文共存，优先使用英文，但中文优先级高；默认使用各自的符号体系，除以上符号外，尽量限制全半角符号的混用；
8. 允许使用某些通用的扩展名用作集合名称进行归类，例如：apk, ppt, pdf 等。
注：getElementById这种历史命名规则属于混用大小写的特殊情况之一；下划线前缀参见python pep8的private variable/method。
四、主分类 / meta set
1. _collection -- 主要指从外部收集而来的数据
2. Archive -- 主要指属于自己的需要归档或超过时效的数据
3. #essential -- 主要指基础必备数据，允许通1和2有重复内容
4. _cache.collection -- 临时未归档的collection数据
5. ~cache -- 可有可无的临时数据
6. ^merge.* -- 最近需要合并的数据；处于锁定状态（即不可）
7. _workspace -- 主要工作区
注1：类似_cache.collection.driver的情况，可以缩略写作_cache.driver；
注2：以上六个为常见示例，诸如_cache.driver一类的主目录视需求增减。
五、分类 / categorizing
1. 类别优先：_collection下有win32分类，如有集合game下的程序全属于win32，但游戏本身是个上层分类，所以game和win32平级。
2. 任务优先：为了完成某个project，可以把相关资源（resource）统一调度到一个分类下。
3. 备份时序优先：备份数据通过合理的时间备注和数据冗余防止版本冲突。
4. 归档结构优先：不常用的数据，则其目录结构也不能经常变动，容易忘。
5. 记忆优先：同样是照片，可以按拍照设备和拍照地点分类。这个主要看数据本身的重要性和个人习惯。
注：其他细节会在末尾进行补充。
六、副分类 / sub set
#essential、~cache、~else、_tool，大部分主分类同样可以作为某个集合下的副分类（二级目录的作用比较难解释，接受这个设定就好）
七、主要词法前缀及建议性保留关键词 / prefix & keyword
参考资料、教程、影视、图片、照片、音乐、音频、通知、学业、项目、数据、备份、同步、设备、驱动、系统镜像、软件、工具、系统工具；3rd(third party), archive, animate, audio, backup, cache, collection, cycle, data, database, dev(develop), delete, device, doc(document), download, else, env(environment), essential, exchange, external, extra, global, hardware, img(image), internal, junction, kb(knowledge base), key, known, local, main, merge, movie, music, node, others, path, pic(pictures), private, post, project, public, push, ref(reference), repo, reserved, res(resources), save, self, serialized, side, software, static, study, syn(sync), sys(system), system_images, tbd(to be done), transfer, tool, unknown, unsure, unused, upload, video, work, workspace.
以上是个人现在常用和曾经用过的一些分类目录名和词缀。
八、补充 or 举例说明 / addition
关于操作：没有备份过的文件，复制优先于移动，以确保数据不应迁移过程的中断而受损。
关于类别优先（priority）：根据子节点数量进行权衡，通常属性类型先于源类别。比如：device.mouse先于device.nokia，win32.Microsoft先于software.windows。
关于中英文混用：中英文的分类逻辑是不一样的，我们平时用的是中文，但计算机本身是英文体系的，所以兼容的工作，最后更多的只能由我们自己来完成（不要幻想有一天中英文能够无缝自动翻译了）。混用的好处主要是解决一部分词义模糊，比如英文里面photos跟picture不是那么好分，中文里面用照片跟图片，或者一个照片一个image就一目了然了。同样，一个词，在中英文里的描述范围也会是有差别的。分类主要是约束划分，所以必要的时候缩小或放宽词义范围也有一定的作用，比如database跟data，在中文下，不加特别区分都可以归类到数据里面。
关于文件的存储及其生命周期（life cycle）：有多少文件你打算真的存一辈子？又有多少文件即便不用存着网上一搜也能找到？数据在一个介质上需要存多久？是否需要依靠传播来提高可延续性？还是说什么样的数据存在手里或是传到网上我们才需要对它以及对自己的行为负责？这都涉及到数据管理的几个基本要求。当然每个人的实际需求是不同的，要求也不能一概而论，所以这里只能概括些通用情况，批判些反面教材。先说，典型的反面教材有：一味的存数据，只收藏从来不消化；到空间不够的时候乱删数据，最后格式化把系统也玩坏了；存储设备出问题了才想起来没有备份数据可用；胡乱传播可能涉嫌违法的或者传播行为受约束的数据等等。片面的针对一种反面情况没有必要，因为凡事总有例外，但就核心的几个问题来说，是明确的。一要尽量避免类似暴饮暴食的情况，因为这样多数是在浪费时间。二是要注意数据和自己的安全，有些不能外泄的数据拿在手里，那是要负责的。三是不能走极端，片面的断舍离，在任何情况来看，都是愚蠢的。最后，如果想要让文件存在的时间长一点，就多传播出去。最极端的情况就是附在一个其他通用的数据包上，比如一个软件或是无损cd的压缩包，里面附上一个你需要的，随意分发到网络或是身边需要的人。当然多数情况，我们还不需要这样做，但有一点是需要考虑的，那就是什么样的文件，放在什么样的网盘，不会出现什么样的特殊情况导致你上传了却下载不了。话说到这也就差不多了，网络终究是靠不住的，需要的，自己会想办法解决（相信说到这里也就能理解为什么有些国家的人单纯靠U盘来传，用机械硬盘来存数据了）。
关于存储分隔（partition）以及合理定制workspace：数据的存储和分类，一方面为了提高利用率和可维护性，另一方面也要因地制宜。从这个角度讲，以多账户的功能划分为例，日常账户最好和办公或者开发用的user分开，这样把东西拆开，数据备份和分类在本地环境下的妥协部分就会小很多。至于压缩包使用细节，建议将数据归入一个文件夹之后再进行打包，便于防止命名冲突。然后对于此类可以直接解压的压缩包，可以将名称改为 新建文件夹.-.rar，对于已知的直接打包多文件的压缩包，可标记为新文件夹.+.rar或 .！.zip。
关于数据集合的持久化（persistent）和连续性：用U盘一类的闪存作为长期存储介质，虽然在一致性（consistent）和期限上不够可靠，但拥有极佳的携带体积（比如一个信封塞光盘可能会裂开，但32个64g的tf卡毫无压力）。磁带作为一种极端措施，虽有足够的存储密度，但不是常人可以或需要考虑的。软盘跟光盘基本上也是优先考虑光盘，硬盘优先机械，这都是废话，但引申出两个实用方案，即存储介质的虚拟化，比如iso和vhd。对于相对固定的东西，iso要比rar等压缩方案来得方便，虽然多点磁盘占用，但可以直接挂载，只是更新麻烦（rar之流虽也有存储不压缩，但系统层面支持直接挂在的大多不通用，除了zip）。对于相对不那么固定的，也有vhd可以差分备份，不过也损失一点点读写性能。再极端的情况，就是整体虚拟化，比如不常用的工作环境下的一整套对性能要求不高的软件，放到一个虚拟机里。但最后凡是涉及到备份步骤的，不可避免涉及到一个连续的问题，跨备份的数据虽然可以通过合并快照一类的形式解决，若没有一个介质作为中转，则会比较麻烦。另外，随着时间的推移，如果一个固有集合太久不去使用，也会像自己的代码三月不见全然陌生一样，故必要的备注描述以及日志的记录分析还是很用帮助的。
关于简单的必要性：文件的管理和调用可以有很多种方案，Windows NT6.x开始自带的库，Total commander这样的第三方资源管理器，everything/listary这样以搜索为主的辅助软件，以及各种标签式的category+tag双分类的管理软件，我大概都用过一些。但最后还是放弃了在文件管理这个底层环节依赖任何一种软件。因为这种事情的环境因素是需要逆推的，以一块移动硬盘为例，要想兼容主流操作系统，那就只能用NTFS，你用NTFS，那就摆脱不了NTFS的各种落后或者相对多余的设定（比如ACL）。所以再往后就是文件系统限制了软件，软件限制了自己。最后整个事情就搞复杂了，或者干脆忽略了文件整理这个环节。
关于分类的重要性：我们真的需要2T的移动硬盘来存将近有1T重复且杂乱无章的数据吗？虽然有时候为了解决问题，我们绕过文件整理分类这个环节也是可以的。但是，如果一个人没有记忆，日复一日的重复着同样的操作，细思你作何感想？只有在这种背景下人们才会意识到，辅助工具终究只是辅助工具，编辑器再屌也拯救不了你那屎一样的编程水平（没有针对emacs/vim的意思）。所以在全篇这样的基调下我只想最后强调一点，或许也就是写这篇总结的用意：这世上根本没有什么拖延症，有的只是各种类似搜索后遗症一样的坏习惯。我们当然可以每天用着百度google，用着拼音输入法，但总有一天会意识到，提笔写字的重要性，和提笔忘字的尴尬。也只有在那以后我们才有可能意识到，那些没经过沉淀，没有反复训练和强化，没有整理消化过的东西，终究不是自己的。