在看fsnotify源码时，竟然发现，原来windows系统建的文件也是有唯一标识的，只要所在盘符不改变，文件可以随意移动修改重命名，这个标识都不会变化。改变思路不再监控文件变化了，监控变化也有个大问题是，它不递归监控子目录，但自己去加了监控后，将导致目录下有目录时，这个上层的目录不可修改，不可删除，这就是大问题。云端往本地同步时候也将因为这个目录被控制，而拿不到操作权限。
既然，文件或目录创建后，在本地也有标识这个文件/目录的唯一值，将用这个联系起来，比如用map key value，绑它的标识暂且叫ino吧，绑index和（文件路径、文件云端id ，父级id,本地创建时间修改时间，md5值，等有用的信息），当然路径可能变化，可能被重命名，也可能被修改，不管怎样，ino不会变。
可能还需要路径作为key，ino作为value是另外一个map
对于首次同步，是要云端本地互相同步补充。后续的同步，是要同步变化的部分。
原先云端往本地同步的逻辑不变，对比新旧xml，拿到云端要对本地要做的操作，作业到本地，这时候，根据不同操作，要添加或者删除或者更新一下前面的map。比如文件被覆盖了后，ino应该会变化，根据路径拿到对应的ino，其实不从这个map拿，只要路径存在，就可拿到ino，更新一下当前文件的创建时间，修改时间，md5值。如果云端有删除，要从map中delete掉。文件有md5值变化，要重新下载覆盖，也补充到ino。重命名，修改map中的数据。不存在的文件下载并补充到map，被覆盖的文件从map中移除，创建的目录也要补充到map。要考虑中间某个操作可能失败。上面这段是云端同步至本地完成，会产生一个新的xml，这里有当前所有文件或目录的详细数据，包括文件或目录在云端的id和dirId。
上面的作业完成之后，但是不保证这期间，这些文件会不会被本地动，这样的话，这个map与最新的情况可能并不一致，但是这个map可以作为，本地同步至云端时的参考。
一个协程定期，比如几秒钟执行一次，更新一个最新的map，这里可能会有些文件信息的缺失，比如还未同步至云端的新建的文件或目录并没有id和父id。可以通过通道发送给另外一个协程，另外一个协程拿一次它的信息进行数据补充。
参考前面的map数据，补充进去本地文件云端相关的id，父id，当前这个目录里的路径视为是最新的，云端同步过来的，不要再重复往云端同步，比如有个标记，后续再又本地修改，把标记置位。之前的map是老的路径，当往云端作业时，依据路径和文件md5变化，得知往云端作业是是要转移路径，重命名，还是覆盖上传，这三个操作可能一条比较有需要多个操作，可能既要重命名又要覆盖上传，既要转移又要重命名，又要覆盖上传。文件md5发生变化是需要上传。以及删除（老的map中有的，新的map已经没有了），新增（老的有，新的没有的）。也可以在本地做这些同步期间暂时把这些所有文件或目录锁定，不允许操作，但这个动作一定要云盘同步至本地后，这样就保证了，不会刚要传云端就操作本地，导致本地往云端同步，真的去作业时，发现原文件找不着了而出错。等这一批作业完毕后，再允许随便操作。可以只锁需要同步至云端，尚未完成的部分。已经完成就解除锁定，这样缩小锁定的范围，其他文件或目录仍然是可以操作的。
网友评论