文件分类系统2024
文件分类系统2024
这里只是记录 “增添” 的部分，以及 “重要” 的部分，其实部分延续之前分类系统习惯。
分类原则
Big3部分
基于V5版本有些改进，也是我分类系统的最重要的原则之一
更新日志
V5中的旧定义
Big3 在之前 ThreeRoot (见分类原则笔记) 中的定义是：性能、管理、隐私
2024版的定义的不同，给出了更多的层次：
文件Big3 | |
分类 | 硬盘、(编码)格式、(编码)加密 |
特点 | 当一个文件被存储到你的电脑后，该文件自身就拥有这三种特性，不随人为意志改变。 比如说一个文件认为是隐私还是公开，可以在一念之间被修改。但他是否加密，则是客观事实。 |
影响Big3 | |
分类 | 性能、管理、隐私 |
特点 | 这些是抽象的概念，根据打开的方式和处理软件的默认行为不同，特点不同。 比如说在某个弱加密软件中某文件属于隐私，但在电脑的资源管理器中你能直接打开看到。 |
软件Big3 | |
分类 | 分区管理软件、专项管理软件、加密管理软件 |
特点 | 这里才是对分类系统有指导意义的三类 |
Big3细分
（这里Big三不分先后，但Big分的细分有先后。从影响程度从高到低排）
- 性能
- 硬盘 会影响性能 (物理天然性能)
- 格式 会影响性能 (文件格式天然有性能差异)
- 加密 会影响性能 (加密, 但似乎影响很低)
- 管理
- 跨硬盘 会影响管理
- 跨格式 会影响管理
- 跨加密 会影响管理
- 隐私
- 硬盘隔绝 会影响隐私
- 加密隔绝 会影响隐私
- 格式不同 会影响隐私
除了上面提到的外，一些 “优化” 也能够影响他们。例如对系统部分的内存空间提高优先级，从而使其在调度算法中占据优势，这是可能的。
优先级
原则
优先级原则一：优先级只是层级优先级，不代表重要程度
优先级原则二：大家排高优先级其实都有道理和应用场景，我这里给出的不意味着就是对的。并且其实很多时候大家都是紧耦合，不是完全区分的
原因
隐私>硬盘： 最极致的隐私保护，必然是物理隔绝。但感觉个人用不到这么极致- 硬盘>隐私： 一方面隐私盘只放隐私、公开盘只放公开，对操作和硬盘数都太苛刻了。二来我们不允许在公有盘中放私有信息，但应允许在私有盘放公有信息 (只是禁止将私有盘中的公有资料发布出去，可能有风险)
隐私>管理： (同点一)- 管理>隐私： 常用的管理软件如 GitHub Desktop，管理对象就是同时包含各种权限的
管理>硬盘： 从 “分布式存储系统” 的角度，集群子机可能面临宕机/替换，管理不应该依赖于硬盘- 硬盘>管理： 大部分管理系统其实不支持多文件夹并集。如Git库/笔记库/音乐库/图片库，虽然看起来是缓存多个路径 (多个库) 方便随时切换，但同一时间只能打开一个。并不具备像分布式系统那种分布式查询能力
我的排序、多层嵌套问题
而在电脑文件管理方面，我的优先级为：(前三个是宏观来看的，后三个才是在物理上有标记，六个之后的是二次的嵌套分类)
- 宏观隐私
- 宏观管理
- 宏观硬盘
- 标记硬盘
- 标记管理 (管理类型，而不是文件类型)
- 标记隐私
- 二次标记管理 (详见Er层)
参考一些编程框架
优先级参考：并且，我们可以参考一些现成系统，他山之石，来为我们的分类系统提供支撑：
- 参考 “面向对象”：
- 程序文件 = 硬盘
- 同父类的类 = 同类型、同格式、同管理对象
- 类方法的可访问性 = 隐私
- 排序：硬盘>格式>加密
- 参考 “Redis分布式存储系统”：
- 集群子机 = 硬盘
- Redis的数据结构 = 格式、管理对象
- 存储中的访问权限字段 = 隐私 (假设有)
- 排序：硬盘>格式>加密
- 参考 “资源网站”：
- 不同的资源网站 = 硬盘
- 先按教程类型分类 = 格式、管理对象
- 然后部分教程免费部分收费 = 隐私
- 排序：硬盘>格式>加密
Er2部分
这条原则，也是由Big3的格式/管理层，延伸出来的
二次管理
这里是属于第二次管理的。为什么会有两次：
- 硬盘的多层管理：
- 如：不同的电脑、不同的磁盘。前者第一层，后者第二层。
- 格式的多层管理：
- 如：处理各种格式 (3D/Plant/Video/...) 工具的 (软件/文档/教程/项目/...)。 后者属于第一层格式，前者是第二层格式。
- 如：而且格式可能有嵌套，如一个泛用格式管理软件 > 文档管理软件 > md/论文管理软件
- 格式一层，通常叫管理层。格式二层，通常叫处理层，也叫Er层 (processor的意思)。而Er层又有两层结构，所以我记为Er2层。
- 权限的多层管理：
- 如：根据不同项目组 (技术/财务/销售/...) 有不同的权限，每个项目组中的人员 (组长/组员/...) 又有不同的权限。
不过硬盘和权限都可以扁平化，而非嵌套化。通常多层情况还是格式比较多。
分类树
前四层名字：
硬盘层 |
管理层 |
隐私层 |
Er层 |
Er子层 (根据Er层有所不同)/ |
前三层结构 (根据Big3)
(括号路径为虚拟路径)
系统盘 | ||
系统 | ||
ResDefault | 如果空间不够可以移至主盘中 | |
主盘 | 特点：未归档、热资源 | |
Soft | 软件 | 特点：不用归档 |
SoftDev | 生产力分类 | |
SoftIO | IO分类 | |
SoftOther | 其他分类 | |
ResGit | 工程 | 可能包括不使用Git管理的工程 特点：需要归档 |
Private | 私有 | |
Public | 公有 | |
Work | 特定权限 | |
ResDefault | 默认下载/存储的资源 | 归档过的资源都应该属于冷数据。 附加：注意这里需要将默认保存放在这 特点：需要归档 |
Private | ||
| 很少会有，几乎强制为Private | |
| 很少会有，几乎强制为Private | |
备份盘 | 特点：已归档、冷资源。如果需要热运行，那么应该拷贝一份 (除非是txt查看编辑这类低消耗工作) | |
ResInstaller | (软件网) 安装器 | 包括 软件、系统。虽然一般都是公有权限，但为了一致性，还是要分的 |
Private | ||
Public | ||
Work | ||
ResGit | (Github网) | 同上 |
Private | ||
Public | ||
Work | ||
ResNormal | (资源网) | |
Private | ||
Public | ||
Work | ||
ResRetrieval_Billfish | (图片网) | |
ResTutorial | (教程网) |
第四、五层结构 (根据Er2)
以软件/软件安装器路径为例 (括号路径为虚拟路径)
(硬件层) | |
(管理层) | 仅以Soft/ResInstall为例 |
(隐私层) | |
Private/Public/Work | |
(Er层) | |
Editor | 特点：1. 按性能类型分类, 2. 可编辑 |
3D | |
Dev | |
Doc | |
Mix | |
Plane | |
Video | |
VIrtual | |
Voice | |
Viewer | 特点：1. 重视内容而非性能, 按记录内容分类, 2. 一般是只读 |
InfoDoc | |
InfoTeach | |
Other | 特点：仅使用，或一些抽象的东西 |
IO | |
... | |
社交软件/资料 | |
游戏 | |
.../ |
第四层往后就不统一了，前四层统一
宏观扩展
优先级：软件 > 普通资源
软件部分
- 普通软件
- 这个就不用解释了吧
- 软件环境
- 编程环境等，本质上也是一些可运行文件加资源文件的集合，也是数据+算法。本质是软件
- 软件插件/脚本
- 普通软件可能依赖于系统、也可能依赖于环境/软件、而插件依赖于软件。其实原理都是一样的
- 软件可以将外部依赖包装起来，插件本身也有可能这么做而做成独立软件。所以本质是一样的
- 软件不一定强依赖特点系统 (多平台软件)，插件也不一定强依赖特点软件 (多软件通用插件)
- 系统/虚拟系统
- 系统算软件，虚拟系统是可以在系统的层级上进行安装的，从这点看他是软件
- VMWare的VM镜像。这玩意会在使用过程中自编辑，所以本质是软件，无法当成文件冷资源看待
- DockerFile和Vagrant。虽然单文件本身不算，但我可以把他们理解成一个指向系统iso的网页链接，所以本质也是软件
- 工作区与软件缓存
- Installer没有这部分，这部分是专门针对安装后的Soft路径写的
- 指运行中的软件的一些缓存路径等，应该放在软件的文件夹中。考量是：这些东西会随着软件的运行自修改，且不随人为意志不可控地进行 (工作区看情况，没有运行热更新的也可以不放在软件路径中)
资源部分
略
其他
.billfish和.obsidian虽然包含一部分缓存，但感觉无伤大雅，不算热资源。 一方面应该都是小缓存，另一方面应该是针对库的缓存，而不是软件缓存，后者应该还是在软件文件夹或C盘。