者安装点共享标识符在客户端中本 地改变）。共享标识符是唯一Id并且对客户端不透明。因此，对于客户端上的安装点列表中 的每个安装点与服务器上的列表比较。因此，如果用于任何安装点的路径或者共享标识符 不同，则客户端重命名那些安装点。
[0036]如果用于客户端上的本地安装点元数据(例如，共享的文件夹）的共享标识符不同 于服务器上的安装点元数据(元数据包括安装点的路径或者安装点的共享标识符）（是），则 客户端通过向原安装点名称的末尾追加".PRIVATE"或者另一前缀、去除本地共享标识符并 且使对应的安装点进入规则文件夹(例如，私有文件夹）中来重命名这些安装点名称(405)。 之后，这些文件夹将被发送到服务器作为新文件和文件夹。新名称向用户指示在文件夹的 共享状态属性中存在冲突并且它们可以再次共享文件夹。
[0037]完成比较共享的文件夹的安装点出现在已经比较了所有安装点时(406)。如果安 装点尚未都被比较(否），则用下一安装点重新迭代比较(403)。在完成比较时(是），客户端 遍历整个本地状态并且向服务器发送具有版本(例如，在一个点同步）的所有本地项目（例 如，文件、文件夹安装点），其中恢复标志被设置成真(407)。不要求恢复标志是布尔标志;其 它实现方式根据希望的实现方式也是可能的。例如，一个示例实现方式可以根据管理文件 的客户端自从客户端上次与服务器同步起是否具有本地改变而涉及'recoveryPut'（PUT) 或者'recoveryUpdate'（UPDATE)这些值。发送本地项目和与服务器的同步过程涉及具有关 于每个文件的文件名、文件路径、哈希和大小的信息的REST API PUT。如果服务器还不具有 文件的内容，则它也可以包含它们。服务器调和这些PUT与现有状态。关于图5A进一步描述 恢复PUT的细节。
[0038]在调和所有PUT时，客户端向服务器通知恢复已经被完成(408)。客户端然后向服 务器发送不具有版本（例如，从未与服务器同步）的所有本地文件作为正常操作或者PUT (409) 。这些文件变得与在稳定状态中相同被添加到服务器。这一步骤包括由更早的过程重 命名成".PRIVATE"的任何文件夹。客户端然后从服务器拉取关于用户的所有文件的元数据 (410) 。这将客户端带到与服务器状态最新。
[0039]图4B和图4C图示了根据示例实现方式的流程图执行的示例。在图4B的示例中，恢 复点是在从备份的恢复已经完成之后的服务器数据的状态。Clientl具有被命名为 SharedFolderl的私有文件夹并且不具有任何共享的文件夹。对于Userl，Clientl与服务器 通信并且服务器指示它在恢复模式中。客户端比较本地安装点表中的安装点元数据与服务 器上的服务器表中的安装点元数据。服务器上的安装点名称ShareFolderl不存在于客户端 上，但是客户端具有私有文件夹，该私有文件夹具有相同名称。当没有如在本公开内容中描 述的重命名实现方式时，服务器可能开始共享用户的私有文件夹"SharedFolderl"的所有 私有内容。为了避免该情形，客户端将私有文件夹"SharedFolderl"重命名成 "SharedFolderl .PRIVATE"。客户端也从服务器拉取安装点SharedFolderl细节。
[0040]在图4C的示例中，恢复点是在从备份的恢复已经完成之后的服务器的数据的状 态。Clientl在灾难出现之前的某个时间将它的共享文件夹安装点从"SharedFolderl"重命 名成"NewShare"，并且这是clientl的当前状态。用于Userl的Clientl与服务器通信并且服 务器指示它在恢复模式中。Clientl比较本地安装点表中的安装点元数据与服务器表中的 在服务器上的安装点元数据。服务器上的安装点名称(安装点的路径）"SharedFolderl"不 同于客户端上的安装点名称(安装点的路径）"NeWhare"。因此，使"NeWhare"进入私有文 件夹中并且它的新名称是"NewShare · PRIVATE"。
[0041]在以上示例中，安装点名称是使用的元数据的一个示例。相似重命名也可以出现 在共享标识符对于具有相同路径的文件夹而言不同时。
[0042]恢复Put和恢复Update的示例实现方式
[0043]在客户端发送用于恢复的文件时，客户端使用REST PUT操作。在这一操作期间，可 以存在用于文件的两个可能性:它们确切地是与在它们被同步时相同的内容，或者它们在 文件已经被同步之后由用户本地修改。第一情况将被称为PUT，并且第二情况将被称为 UPDATE。更具体地，如果与文件关联的当前元数据(例如，大小和/或修改时间）尚未从客户 端已经在它的本地数据库中记录的元数据改变(例如，文件自从与服务器的上次同步起尚 未本地改变)则可以使用PUT的恢复过程。如果文件自从与上次同步到服务器起已经本地改 变(例如，用户本地更新文件而服务器停机并且未接受上传），则可以使用UPDATE的恢复过 程。在服务器变成可用(例如，从故障恢复)并且向客户端通知该恢复时，客户端将本地改变 的文件发送作为UPDATE，因为文件自从与服务器的上次成功同步起已经本地改变。在PUT与 UPDATE之间的不同是文件是否自从客户端上次与服务器同步起已经被本地改变。在每种情 况下，服务器尝试使用来自客户端的数据来恢复自身。
[0044] 在以下示例中，ClientVersion是由客户端在PUT或者UPDATE中发送的版本。 ServerVersion是服务器上的文件的版本。
[0045] 在服务器经过恢复时，用RecoveryVersion标记每个文件系统，并且在恢复期间未 改变RecoveryVersion。这一1^(3〇￥61}^6^;[011在图54的恢复开始时被设置为比文件系统上 的所有文件的最高版本更高的版本。在恢复期间，大于或者等于RecoveryVersion的任何遇 到的ClientVersion向系统指示遇到的更高ClientVersion在从服务器的备份恢复之后被 创建。0116]11：￥6^；[011、1^(30￥6^￥6^；[011和361^61^6^；[011可以被实施为指不文件版本号的 元数据或者根据希望的实现方式通过其它方法。
[0046] 利用以下实现方式，由此可以有可能接受服务器上的所有文件内容而创建更少冲 突文件。在相关领域实现方式中，无论何时ClientVersion未匹配ServerVersion都将创建 冲突文件。然而，通过利用恢复put，示例实现方式允许在服务器恢复之后对文件的第一更 新成功。如图5A和图5B中描绘的示例实现方式图示了由服务器在服务器与客户端之间的调 和过程。在开始如图5A和图5B中所示的过程之前，服务器参考从每个客户端发送的用于每 个文件的恢复标志，并且确定客户端是否请求用于每个文件的恢复过程HJT或者UPDATE。如 以上描述的那样，恢复标志可以根据文件自从它上次与服务器同步起是否具有局部改变来 包括值'recoveryPut'（PUT)或者'recoveryUpdate'（UPDATE) 〇
[0047] 图5A图示了根据示例实现方式的用于恢复PUT的流程图。恢复PUT可以如以上描述 的那样按照客户端恢复文件的形式。服务器从客户端接收文件PUT (500 )以获得 ClientVersion。执行比较以查明ClientVersion是否比RecoveryVersion更加新（501)。如 果不是（否），则忽略PUT(502)，因为ClientVersion是在可以通过使用服务器和外部存储装 置中的文件而被恢复的最高版本之前的版本，因此服务器已经最新(服务器已经具有客户 端版本），并且由此可以忽略PUT。
[0048] 否则（是）执行检查（503)以查明ServerVersion是否为空（即，服务器不具有副 本）。如果ServerVersion为空(是），则执行PUT以将文件存储作为新文件(504)，因为文件并 未存在于服务器上。否则（否）执行检查（505)以查明ServerVersion是否比 RecoveryVersion更旧。如果ServerVersion比RecoveryVersion更旧（在505中为是），则它 指示服务器尚未从客户端接收具有比RecoveryVersion更加新的ClientVersion的另一文 件。如果ServerVersion比RecoveryVersion更加新(在505中为