Allway sync 文件同步软件

基本需求

对于文件的同步需求，如下：

1. 识别更新后的文件（很多同步工具都是基于系统时间，一错全错）

2. 不基于系统时间识别文件修改情况

3. 支持任意格式

4. 可以选择删除不对等的文件

5. 增量备份（高端）

6. 多端同步（即支持各类文件传输协议）

Allway sync 文件同步软件

有好多软件都有这个软件的影子

小想法

下面就是我对这个软件两个小点的想法

第一个，不基于系统时间识别文件修改状态

第二个，增量备份

不基于系统时间识别文件修改状态

没有时间做参考系坐标原点，还是很容易乱套的。有一些软件的破解也是往系统时间上面做文章，这个点在正常写软件的时候也不好想到，奇奇怪怪的角度。

有一些权益的增加，必然会有一些舍弃。不用时间了，就需要用些空间。

基本思路是给文件打点，以文件名为索引，制定一张表。这张表包括这个文件的基本信息，每种文件格式都有一个特征头部，诶~。文件名，文件头部特征值，文件哈希值，巴拉巴拉巴拉

文件每有一次变更，就在表里面打个点。对比文件哈希值，一个文件有一点点变化，哈希值出现雪崩效应。对比哈希值是合理的，况且计算哈希值也花不了多少计算资源。

这里面还有一个基准点，文件用这个软件创建之后，形成两个对等的表。一个用来记时间（创建时间用秒表示），一个用来记变化。

简单点说就是，利用哈希值的雪崩效应，判定文件更新前后。

增量备份

增量就是只修改文件的一部分同时也只更新这一部分，达到备份的目的。

那可能要问了，打开文件修改，再保存，不就是增量修改么。格局小了格局小了，文件打开基于某个格式，各种格式的压缩方式又不一样。要是能寻求一种，底层的增量哈哈哈哈哪得省多少钱啊

这是个大课题，是个恰饭的点。奈何等级不够，只搞懂了一点点。

现在的增量备份是用CPU资源换带宽流量资源。也就是说这玩意儿就是算。

当一个文件很大的时候，我们可以把它分块，一个块一个块的储存。这时候，文件太过散乱了，需要一个程序或者说一个表（BT种子就是这么一回事），把这个块的名字存起来（还是哈希值）。

既然是要备份，也就是说我们修改一部分，后面还是要用的，文件不能损坏。

文件修改了一部分，整个去分块，对比之前的分块哈希，有变更的分块就是需要增量备份的块。

混合在一起 ~  

数据这样分块存储，跟数据帧是一个意思，只是一个大一个小一点。

我这里有个疑问，数据的小变动会不会引起数据底层（0101010这块的）的大变动？

按我的想法，数据能表现成一个稀疏矩阵的时候，不会引起大的变动。（空间换信息这样的）

当然，我也知道压缩这个概念，字典中字段的数量决定了可压缩的极限。一个格式的能支持压缩率越高，它相对而言冗余的信息就越多。

压缩是个数学问题，留给数学家和编码学家。