CN108710533B - 共享和同步电子保存的文件 - Google Patents

Abstract

共享和同步电子保存的文件。本公开的各个方面针对的是使电子保存文件在云实体和多个计算机、系统、装置和/或用户之间的共享和同步变得更容易的体系结构、方法、系统和结构。一种特定的例证体系结构包括云文件系统和客户端文件系统内的文件系统变更的同时确定，响应确定的文件系统变更所必须的文件系统操作的串行排序，和文件系统操作的同时执行，以致使云文件系统和客户端计算机文件系统同步。

Description

共享和同步电子保存的文件

分案说明

本申请属于申请日为2013年4月2日的中国发明专利申请No.201380029205.6的分案申请。

相关申请的引用

以下美国专利申请是和本申请在同一日期提交的，被转让给相同的受让人，并包含在某些方面与本申请的主题相关的主题。这些专利申请在此引为参考。

序列号13/453,678，2012年4月23日申请，代理人卷号110822-78062；

序列号13/453,860，2012年4月23日申请，代理人卷号110822-78067；

序列号13/453,909，2012年4月23日申请，代理人卷号110822-78063；

序列号13/453,799，2012年4月23日申请，代理人卷号110822-78182；和

序列号13/453,748，2012年4月23日申请，代理人卷号110822-78183。

技术领域

本公开涉及涉及电子保存文件在云实体、服务器计算机、桌上型计算机、个人计算机、便携式计算机、移动计算机、允许web的计算机和其它计算机，包括平板计算机、个人数字助手(PDA)和智能电话机之间的共享和同步。

背景技术

定义大部分现代社会的连网的移动计算环境带来无数便利和生产率益处。尽管存在这样的益处，但是管理同时存在于众多计算机、系统和装置上的电子保存文件变得日益困难。例如，即使对于最富有经验的用户，记录并访问保存在或者跨一个或多个办公计算机、膝上型计算机、家用计算机、移动计算机和可拆卸磁盘保存的电子保存文件的最新版本或者修订本也时常变得困难。这种电子保存文件时常同时被许多不同用户全球访问、使用或改变的事实增大了这种困难性。

发明内容

简要地，本公开的各个方面针对的是使电子保存文件在云实体和许多计算机、系统、装置和/或用户之间的共享和同步变得更容易的体系结构、方法、系统和结构。

按照本公开的一个方面，最初在云实体内生成电子保存文件，所述电子保存文件随后被复制，并与一个或多个客户端计算系统同步。类似地，在客户端计算系统内生成的电子保存文件随后被复制，并与云实体和其它客户端计算系统同步。

按照本公开的一个方面，在同步操作期间，客户端判定是否把电子保存在云中的文件下载/复制到客户端。如果文件是特定类型的文件，那么它不被下载/复制到客户端。相反，在客户端本地创建包含到电子保存在云中的文件的链接的文件。有利的是，可以使本地电子保存的文件成为指示其云发源的种类。更有利的是，本地文件可用于调用浏览器，以访问电子保存在云中的文件，云可进一步利用云计算服务来访问所述文件。

有利地，并且按照按照本公开的另一个方面，这种共享和同步是用户可管理的，从而允许共享和同步组和/或系统的形成。

按照本公开的另一个方面，客户端计算系统包括同时分别监视和检测对被观察的本地文件系统和云文件系统的变更的本地观察器(Local WATCHER)和云观察器(CloudWATCHER)。检测到的变更被用于生成工作项目，所述工作项目被排序并有选择地发送给多个工作器(WORKER)，以便同时处理。

按照本公开的一个方面，自动与共享文件夹的任何授权用户共享和同步放入该共享文件夹中的电子保存文件。

按照本公开的另一个方面，放入共享文件夹中的电子保存文件被自动保存在云存储系统内。

按照本公开的另一个方面，放入共享文件件中的电子保存文件跨多个系统、装置和网络，在线和离线地自动“跟随”用户。对放入共享文件夹中的电子保存文件的任何变更被自动更新和同步到云及其它计算机和装置。

提供本发明内容部分是为了识别下面在具体实施方式部分中进一步说明的本公开的一些方面。本发明内容部分并不意图识别本公开的关键或基本特征，也不意图限制任何权利要求的范围。

术语“方面”应被理解成“至少一个方面”。附图中举例而非限制地图解说明了这里说明的本公开的上述各个方面和其它各个方面。

附图说明

参考附图，可更完整地理解本公开，附图中：

图1是描述按照本公开的一个方面的共享和同步电子保存文件的例证配置的示意图；

图2是描述按照本公开的又一个方面的共享和同步电子保存文件的又一个例证配置的示意图；

图3是描述按照本公开的另一个方面的共享和同步电子保存文件的另一个例证体系结构的示意图；

图3a-3c是描述按照本公开的一个方面的电子保存文件的例证拖放操作和同步状态的示意图；

图4a是描述按照本公开的一个方面的SyncCLIENT的例证功能操作的示意图；

图4b是描述按照本公开的一个方面，当在云中产生文档，随后把该文档传送给SyncCLIENT时的事件的例证序列的示意图；

图4c是说明当借助第三方应用产生文档，随后以到云或云站点的链接的形式，与SyncCLIENT共享/同步所述文档时的事件的例证序列的示意图；

图4d是描述按照本公开的一个方面，SyncCLIENT和云之间的例证映射的示意图；

图4e是描述按照本公开的一个方面，SyncCLIENT和云之间的例证同步的示意图；

图4f是描述按照本公开的一个方面，SyncCLIENT和云之间的另外的例证同步的示意图；

图4g是说明与云中的多个文件夹相关的单个文件和SyncCLIENT的例证同步的示意图；

图5是描述按照本公开的一个方面的SyncCLIENT的例证体系结构的示意方框图；

图5a是说明按照本公开的一个方面的事件聚合器的例证操作概况的示意方框图；

图5b是说明按照本公开的一个方面的事件聚合器的例证操作的示意方框图；

图5c是说明按照本公开的一个方面的事件聚合器的例证操作概况的流程图；

图6是说明按照本公开的一个方面，通过利用图表，检测对云文件系统和本地文件系统的变更的云观察器和本地观察器((类型-2)-2)的示意方框图；

图6a是说明按照本公开的一个方面，根据SyncCLIENT从云接收的变更日志，确定当前云状态的云观察器的示意方框图；

图7是说明按照本公开的一个方面，抓取器(FETCHER)进行的工作项目的处理，和工作器进行的随后操作的示意方框图；

图8是说明抓取器内的常规工作项目的串行化的示意方框图；

图9是描述实现按照本公开的一个方面的共享和同步电子保存文件的例证方法和系统的典型计算机系统的示意图。

借助附图和具体实施方式，更充分地说明例证实施例。不过，本发明可用各种形式体现，并不局限于在附图和具体实施方式中说明的具体实施例。

具体实施方式

下面仅仅举例说明本公开的原理。从而应认识到，本领域的技术人员能够设计出各种配置，尽管未在这里明确说明或表示，不过，所述各种配置可具体体现本公开的原理，从而包含在本公开的精神和范围之内。

此外，这里列举的所有例子和条件语言主要仅仅用于教学用途，以帮助理解本公开的原理，和发明人为促进本领域技术而贡献的原理，应被理解成并不限于这样的具体陈述的例子和条件。

此外，这里列举本公开的各种原理、方面和实施例的所有陈述，以及本公开的具体例子包含其结构和功能等同物。另外，这样的等同物既包括目前已知的等同物，也包括未来出现的等同物，即，出现的实现相同功能，而与结构无关的任何元件。

从而，例如，本领域的技术人员会理解这里的任何方框图代表具体体现本公开的原理的例证电路的概念图。类似地，应理解任何流程图、状态转变图、伪代码等都代表在计算机可读介质中实质表现的，从而由计算机或处理器执行的各种处理，而不论所述计算机或处理器是否被明确示出。

通过利用专用硬件，以及与适当的软件结合能够执行软件的硬件，可提供附图中所示的各个元件，包括标记为“处理器”的任何功能块的功能。当由处理器提供时，所述功能可由单个专用处理器，由单个共享处理器，或者由多个单独的处理器(其中的一些可被共享)提供。此外，术语“处理器”或“控制器”的明确使用不应被解释成仅仅指的是能够执行软件的硬件，可隐含地包括(但不限于)数字信号处理器(DSP)硬件，网络处理器，专用集成电路(ASIC)，现场可编程门阵列(FPGA)，用于保存软件的只读存储器(ROM)，随机存取存储器(RAM)，和非易失性存储器。也可包括其它常规和/或定制的硬件。

这里，软件模块，或者简单地，被暗示为软件的模块可被表示成指示处理步骤的执行和/或文本描述的流程图要素或其它要素的任意组合。这样的模块可由明确或隐含所示的硬件执行。

除非这里明确地另有说明，否则附图不是按比例绘制的。

现在，提供一些非限制性的说明性例子，所述例子举例说明本公开的各种配置和备选实施例的几个操作方面。

通常，并且如这里使用的一样，电子保存文件是一种抽象概念。它提供一种把一组数据打包到可识别的单元中的便利方式，所述可识别单元又可由计算机系统管理、保存、检索和操作。首先参见图1，图中表示了说明按照本公开的一个方面，共享和同步电子保存文件的例证配置100的示意图。

图1中描述的是个人计算机110，和个人计算机110借助一种或多种已知的连网技术125与之交互的“云”120。

本领域的技术人员易于理解，云120是诸如存储、计算和应用之类连网资源的模型。例如，云计算通常指的是作为服务的计算的交付，从而共享资源、应用、软件、数据和信息通过诸如因特网之类的网络，以服务的形式被提供给计算机和其它装置。类似地，云存储通常指的是借助网络，由云120提供的电子存储资源(例如，电子文件系统)。

有利的是，云计算和/或云存储可以向各个用户只提供为特定任务所需的那些资源，从而消除为空闲或不用的资源付款。更有利的是，用户可以访问任何最新的软件和基础结构提供，从而促进兼容性和生产力。

最后，在利用因特网访问云120的情况下，云计算和/或云存储通常向用户提供从可以获得因特网接入机构的任何地方，对云资源的访问。

有利的是，图1中描述的连网技术125可提供直接或经因特网服务提供商，对云120的因特网接入。用于云接入的典型连网技术包括(但不限于)拔号、租用线路、ISDN、光纤、宽带、电力线宽带、光纤入户、DSL/ADSL/SDSL、WiFi、WiMax、电缆、卫星、移动电话和T载波等。已知的网络互连协议，即，TCP/IP可以连同更高级的协议，即，HTTP一起结合这样的技术使用，以实现期望的与云120或其它网络资源的通信。

图1中还描述了存在于个人计算机110的存储系统中的许多电子文件夹112、114、116。本领域的技术人员易于理解，如图1中所示的电子文件夹是一种虚拟容器，其中可以保持和组织多组电子保存文件。

进一步可认识到，诸如在个人计算机110运行的操作系统，比如Windows、OS X、LINUX之类的当代计算机操作系统通常包括对可包含成千上万个文件夹的电子文件系统的支持。通过把相关文件保存在公共文件夹中，可以便利地组织电子保存文件。包含在另一个文件夹中的文件夹被称为子文件夹。

本领域的技术人员易于理解，名称“文件夹”类似于在办公室中使用的文件夹，用在几乎所有的当前操作系统的桌面环境中。

文件夹也是一种抽象概念，它提供一种把一组电子保存文件打包到可识别的单元中的便利方式，所述可识别单元又可由计算机系统管理、保存、检索和操作。文件夹通常被计算系统描述成视觉上类似于物理文件夹的图标。

在介绍这些原理之后，现在我们说明按照本公开的一个方面的电子保存文件的共享和同步的某些操作方面。更具体地，并且如图1中所示，个人计算110执行我们一般称为“SyncCLIENT”的客户端同步和共享程序或者一组服务115，

一般来说，客户端程序在特定的计算机上运行，并访问由互补的服务器程序提供的一种或多种服务。服务器程序时常(不过并不总是)在另一个计算机系统上，这种情况下，客户端程序通过网络访问服务。

在本公开的上下文中，如图1中所示，SyncCLIENT 115在个人计算机110上运行，并借助连网技术125，与云120提供的互补服务器服务交互。按照本公开的一个方面，存在于个人计算机110上的一个或多个文件夹被自动复制，并与云120同步。如图1中所示，文件夹112被复制，并与云存储服务130同步，云存储服务130把文件夹112-a电子保存在云文件系统中。

因而，对运行SyncCLIENT 115的个人计算机110上的文件夹112作出的任何增加/删除/变更被反映在云存储130中的文件夹112-a中。有利的是，这种操作导致个人计算机110上的文件夹112内的任何文件或文件夹被自动备份到云存储120。类似地，对云120中的文件夹112-a，或其内容的任何增加/删除/变更会被反映在个人计算机110中的文件夹112或其内容中。

作为另一个例子，并且如前所述，有利的是，除了云存储服务130之外，例证的云120还提供计算服务。例如，许多应用中的任意应用，比如字处理、电子数据表、演示图形、日历功能、个人管理等135可由云120提供，并且可由计算装置150或个人计算机110通过万维网界面，即，例如利用Web浏览器访问。有利地，计算装置150可以是访问云计算资源的“缩减”或“瘦客户端”装置(或者平板装置或智能电话机等)。如所知，这样的瘦客户端通常依赖于其它计算机(即，云计算)来实现其计算任务。

当设置在图1中所示的例证配置内时，计算装置150提供例如利用云计算资源135来编辑例如保存在云存储130和文件夹112-a内的任何可编辑文档的能力。有利的是，可以从计算装置150借助连网技术127能访问云120及其资源的任何地理位置，进行这样的编辑。从而，用户可采用计算装置150创建或编辑或以其它方式利用云计算资源135来修改/创建包含在文件夹112-a内的文件夹或文件。按照本公开的一个方面，自动使对文件夹112-a作出的变更，或者对包含于其中的任何文件或文件夹作出的变更与个人计算机110上的文件夹112同步。

本领域的技术人员易于理解当代计算机系统，比如图1中所示的个人计算机110或其它计算装置150可采用提供允许用户便利地进行文件系统操作的一个或更多用户界面的操作系统，比如WINDOWS、OS/X、LINUX、或类似系统或其衍生物。更具体地，这样的用户接口允许用户利用熟悉的拖放操作、剪贴板操作和命令行操作，处理文件。

当文件系统操作基于这种拖放或者其它熟知的比喻说法的操作时，用户能够便利地选择并把文件、目录(文件夹等)复制、移动、删除到文件系统中的另一个地方。有利的是，可以结合本公开的各个方面使用这种熟悉的用户界面，以把文件移动到个人计算机110上的文件夹112中，随后使之与云文件夹112-a同步。

这里，本领域的技术人员易于理解本公开并不局限于经由用户接口的文件操作。操作系统组件、服务、用户应用等也可进行文件操作。从而，任意这些机构(即，应用)对文件夹112或其内容作出的变更也可同步到云文件夹112-a。

如在图1中所示的例子的上下文中所述，按照本公开的一个方面的同步和共享允许在个人计算机110、150和云120之间的文件和文件夹的自动、双向生成、备份、同步和共享。

现在参见图2，图中表示了说明按照本公开的一个方面的电子文件共享和同步的另一个例证配置200。图2中所示的是许多计算系统，即，在图2中，分别标记为“家用”、“膝上型”和“工作”的计算机210、250和260。各个计算机210、250和260采用已知的网络接入技术225、226和227，比如前面说明的那些接入技术来访问云220，具体地，云存储服务230文件系统。

图2中描述的各个计算机210、250和260执行SyncCLIENT 215、256和267的实例。按照本公开的一个方面，通过执行SyncCLIENT 215，存在于家用计算机210上的一个或多个文件夹被自动复制，并与云存储服务230文件系统同步。在图2中所示的例子中，存在于家用计算机210上的文件夹212被复制，并与云存储服务230文件系统同步，云存储服务230文件系统电子保存文件夹212-a及其电子内容。

如前关于图2中所示的例子所述，膝上型计算机250和工作计算机260被描述成分别执行SyncCLIENT 256和267的实例。从而，并且按照本公开的又一个方面，SyncCLIENT256和267的各个执行实例可在计算机250和260上分别本地复制和同步文件夹212a，作为文件夹212b和212c。结果，存在于家用计算机210上的文件夹212被复制，并且与由云存储服务230文件系统电子保存的文件夹212a，以及分别存在于膝上型计算机250和工作计算机260上的文件夹212b和212c同步。

因而，按照本公开的另一个方面的电子保存文件的共享和同步允许用户在一台计算机上创建/修改电子保存文件(即，在工作计算机260上的文件夹212c中的文件)，并且使这些创建/修改的电子保存文件在其它计算机(即，家用计算机和膝上型计算机210、250)上被自动复制/同步。从而，电子保存文件有效地“跟随”用户从一台计算机到另一台计算机，而不需要任何额外的用户工作。

特别地，并且如图2中所示，这里描述的各个计算机都包括未被复制/同步/与云220或其它计算机共享的许多文件夹。更具体地，家用计算机210被描述成包括未被共享和/或同步的文件夹214和216。类似地，膝上型计算机250被描述成包括未被共享和/或同步的文件夹251和252。最后，工作计算机260被描述成包括未被共享和/或同步的文件夹261。

有利地，并且按照本公开的一个方面，通过SyncCLIENT的操作，与云220和/或其它计算装置和/或用户共享/同步的特定文件夹是用户可管理的。

如前所述，除了任何云存储资源230之外，云220还可提供云计算资源235。从而，通过利用在计算装置、平板电脑或其它便携式计算装置(即，智能电话机)270上运行的由web浏览器访问的云计算资源235的效果，用户也可创建/修改电子保存文件。借助这样的操作，用户可有利地创建/修改保持在云存储服务230文件系统内的文件夹212a中的电子保存文件，那些创建/修改的电子保存文件被分别复制/同步到存在于家用计算机210、膝上型计算机250和工作计算机260上的文件夹212、212b、212c。这样，电子保存文件可在云120中被创建，并复制/同步到有利的是可采用浏览器应用和技术的客户端计算装置，即，家用计算机210、膝上型计算机250、工作计算机260或者其它计算装置270。

注意，我们利用术语创建来描述通过云计算服务的效果的电子保存文件的生成。本领域的技术人员会认识到这里使用的特定词汇并不是限制性的。例如，也可通过云计算服务的效果，在云中生成或产生电子保存文件。类似地，电子保存文件可被云计算服务转换或者识别成可由那些云计算服务操作。因而，对我们的目的而言，这些电子保存文件可被视为是产生、生成或创建的，如下稍微更详细地表示和说明。

另外，尽管迄今说明了电子保存文件在例如单人使用的多个计算机之间的共享和同步，不过，本公开并不局限于此。有利地，并且按照本公开的另一个方面，在多个计算机和用户之间进行电子保存文件的同步和共享。

现在参见图3，图中表示说明按照本公开的一个方面的电子保存文件共享和同步的另一种例证配置300。图3中所示的是由在图3中分别标记为“用户1”、“用户2”和“用户3”的不同的各个用户使用的多个计算系统，即，个人计算机310、350和360。各个计算机310、350和360采用网络接入技术325、326和327，比如前面说明的那些网络接入技术，访问云320，具体地，云存储服务330文件系统。

另外在图3中，各个用户计算机310、350和360执行SyncCLIENT软件315、356和367的实例。

按照本公开的一个方面，通过执行SyncCLIENT软件315的效果，存在于计算机任意之一(例如计算机310)上的一个或多个文件夹被自动复制，并与云存储服务330文件系统同步。在图3中所示的例子中，存在于用户1计算机310上的文件夹312被复制，并与电子保存文件夹312-a的云存储服务330文件系统同步。

如图3中进一步所示，用户2计算机350和用户3计算机360被描述成分别执行SyncCLIENT软件356和367的实例。从而，并且按照本公开的另一个方面，SyncCLIENT软件356和367的各个执行实例可分别以文件夹312b和312c的形式，在用户2和用户3计算机350和360上，本地复制和同步文件夹312a。结果，存在于用户1计算机310上的文件夹312被复制，并与保存在云存储服务330文件系统中的文件夹312a，以及分别存在于用户2计算机350和用户3计算机360上的文件夹312b和312c同步。

因而，按照本公开的另一个方面的电子保存文件的共享和同步允许多个用户在一台计算机(即，用户1计算机310)上创建/修改电子保存文件，并使这些创建/修改的电子保存文件在其它用户的计算机(即，用户2计算机和用户3计算机350、360)上被自动复制/同步。

此外，这些或另外的授权用户可通过例如web浏览器，访问任何云计算服务，以创建/修改包含在保存于云存储服务330文件系统中的文件夹312a内的任何电子保存文件。从而，对文件夹312a内的电子保存文件作出的任何变更被自动复制和/或与用户计算机系统310、350和360上的文件夹同步。

至此，我们说明了涉及多组用户的按照本公开的各个方面的电子保存文件的共享和同步的某些方面。有利地，并且按照本公开的另一个方面，用户可属于共享和同步电子保存文件的多个组。

继续参见图3，注意用户1、用户2和用户3(同时增加了用户4的参与)被描述成共享和同步与文件夹312相关的电子保存文件，即，分别存在于云320、计算机350和360中的文件夹312a、312b和312c。另外，图3中还图示了包括用户2和用户3的共享和同步组。

更具体地，尽管用户2和用户3被描述成共享和同步被表示成存在于与用户2相关的计算机350上的文件夹352。不过，文件夹352以文件夹352a的形式，与云320共享和同步，以与用户3相关的文件夹352b的形式，与计算机360共享和同步。从而，用户2和用户3被描述成两个不同的共享和同步组的一部分。如前所述，有利的是，在共享和同步组，比如图示的那些共享和同步组中包含另外的用户和/或计算机是用户可管理的。

作为操作例，图3a-3c描述按照本公开的一个方面的电子保存文件的拖放操作和随后的同步。本领域的技术人员易于理解，拖放操作是利用图形用户界面机构(即，鼠标或触敏屏幕)“抓住”虚拟对象(比如电子保存文件)，并拖动到另一个虚拟对象(比如文件夹)所在的不同位置的动作。进一步可认识到，这样的操作可便利地用于调用许多种类的动作，或者创建两个抽象对象之间的各类关联。

图3a描述一对重叠的窗口390、392，比如为当代图形用户界面所常见的那些重叠窗口。窗口392中所示的是名为“LIFE CYCLE OF THE ELEPHANT”的电子保存文件393的图标表示。类似地，窗口390包括本地SyncDRIVE文件夹391的图标表示。按照本公开的一个方面，放入本地SyncDRIVE文件夹391中的电子保存文件将被自动复制，并与云(未具体图示)并且可选的是与其它SyncDRIVE客户端(未具体图示)同步。

在这个例子的上下文中，利用以下操作完成基本的拖放序列：把指针移动到电子保存文件393，通过按下鼠标按钮或其它选择机构“抓住”文件393，把文件393“拖动”到SyncDRIVE文件夹391，和通过释放按钮或其它选择机构“放下”文件393。

在进行这种拖放操作之后，如图3b中所示的SyncDRIVE文件夹391的内容的检查表明电子保存文件的副本正在与云同步，如用变更图标394所示，在这个例子中，变更图标394表示电子保存文件正在经历同步。当同步操作结束时，如图3c中所示，与电子保存文件395相关的图标被更新，以进一步反映电子保存文件被同步。

进一步可认识到，可以利用在当代图形用户界面或计算系统中可以获得的各种图标或其它机制，描述如图所示之类的同步状态。例子包括动画和/或可听机制。此外，尽管图3a-3c中所示的例子描述与例证的SyncCLIENT和云相关的同步状态，不过，本领域的技术人员易于认识到本公开并不局限于此，进一步的增强也可描述例如与作为如前所述之类的组的一部分的其它SyncCLIENT的初始、中间和后续下游同步。

在理解本公开的这些特定功能方面的情况下，现在参考图4a，图4a描述按照本公开的一个方面的例证SyncCLIENT 410的简化功能方框图。

如这里所述，SyncCLIENT 410包括至少两个功能元件，即，通过在计算装置上执行SyncCLIENT软件而产生的云观察器440和本地观察器430。简要地，本地观察器430监视和检测对所观察的本地文件系统420的任何变动，而云观察器440监视和检测在驻留于云450中的云文件系统460内的任何有关变更。当在被观察的本地文件系统420或云文件系统460中检测到任何变更时，作为结果产生这两个系统之间的同步。有利地，并且按照本公开的一个方面，在优选实施例中，云观察器440和本地观察器430可同时或并行地工作，取决于它们所工作于的硬件环境。

这里，有益的是讨论按照本公开的一个方面的例证同步，即，当在云中产生文档时，在云和SyncCLIENT之间发生的同步。更具体地，通过利用云计算资源，在云中产生文档，通过利用云存储服务，把文档电子保存在云中，最后使之与一个或多个SyncCLIENT同步。

参见图4b，图中表示说明用户进行的云内的文档的例证产生/创建的示意图。如其中所示，文档是借助移动装置产生/创建的。易于理解并且如前所述，任意各种已知移动装置都适合于与云计算服务交互，以产生可随后借助云存储服务保存在云中的文档。常见的装置包括移动电话机、平板电脑和其它便携式计算装置。特别地，本公开并不局限于移动装置，并且云内的文档的这种产生/创建也可采用桌上型电脑或其它计算装置。特别地，支持浏览器功能的任何装置足以与例证的云计算服务交互。

另外，尽管我们利用术语文档来描述在云内产生和保存的特定电子实体，不过，本公开并不局限于此。更具体地，有利的是，按照本公开，借助云计算服务，在云中可产生字处理文档、电子数据表文档和图形文档等。

从而，一旦借助云计算服务产生了文档，就可利用云存储服务把所述文档电子保存在云中。在例证实施例中，借助云存储服务电子保存的文档将具有与之关联的resourcelD，所述resourcelD唯一地识别云存储中的电子保存文件。

一旦文档被电子保存在云中，它随后就被复制/与SyncCLIENT同步。特别地，在优选实施例中，借助云计算服务产生的电子保存文件不被物理(电子)复制/拷贝到SyncCLIENT。相反，按照本公开的另一个方面，以到云中的电子保存文档文件的链接的形式，使借助云计算服务在云中产生的、并且随后被保存在云中的电子保存文档文件随后与一个或多个SyncCLIENT同步。

按照这种方式，有利的是，在云中产生的电子保存文档不被物理转移到SyncCLIENT。到文档(文件)的链接被传送给SyncCLIENT，在所述SyncCLIENT，所述链接作为包含到云中的文件的链接的电子保存文件，被保存在SyncCLIENT本地文件系统中。更有利的是，包含到云中的文件的链接的电子保存文件可本地展示出指示其云存储的类型。更具体地，这种本地保存文件可以是“.gdoc”类型文件，或者如此指示的任何其它预定类型指定。

因而，在SyncCLIENT文件系统中(在所监视的文件系统中)创建电子保存文件，有利的是，该文件可酌情对用户表现为常规文档、或者文本或其它文件。代替包含保存在云中的电子保存文件的电子内容，本地电子文件包含到云文件的链接。

在优选实施例中，并且如图4b中例证所示，这样的链接可识别资源(文档)，定位资源的手段和任何特定的访问机制。如在图4b的例子中所示，链接可包括指示统一资源定位符(URL)，协议，即，HTTP，服务(DOCS)，resourcelD和类型的组件。本领域的技术人员会认识到，根据需要，在链接中可以包含另外的组件。当如图所示提供这样的链接时，web浏览器的启用可有利地向SyncCLIENT的用户(移动的或固定的)，提供对电子保存在云中的文件的访问，并且有利的是，不会不必要地消耗带宽。

尽管我们把在图4a和4b中所示的操作描述成与在云中产生的那些电子保存文件有关，不过，我们再次指出本公开的教导并不局限于此。更具体地，本公开同样适合于在SyncCLIENT产生的、并且随后如前所述同步/复制到云的那些电子保存文件。

更具体地，用户可在SyncCLIENT计算机上产生电子保存文件，随后把该电子保存文件同步/复制到云。一旦被电子保存在云中，电子保存文件就可被转换和/或修改(如果需要的话)成可便利地由云计算资源和/或云应用中的一个或多个处理的格式。之后，可作为到云中的电子保存文件的链接，使该转换的电子保存文件与一个或多个SyncCLIENT同步。当然，本领域的技术人员会认识到就某些电子文件格式(即，文本文件等)，转换和/或修改不是必需的。从而，当展示这种格式的文件被电子保存在云中时，有利的是可借助前面说明的链接机制，使它们与SyncCLIENT同步，随后从SyncCLIENT访问它们，好像它们发源于云中似的。

特别地，按照本公开的一个方面，不需要借助云计算服务生成文档或其它对象。更具体地，并且现在参考图4c，图中表示借助第三方应用产生文档、借助云服务把所述文档保存在云中、随后以到云中的对象的链接的形式来复制所述文档/使所述文档与SyncCLIENT同步的事件的示意序列。因而，SyncCLIENT认识到云中的文档对象不需要被拷贝到SyncCLIENT，改为生成到该对象的链接，并作为文件本地保存在SyncCLIENT的本地文件系统中。如前所述，例如通过web浏览器，可从SyncCLIENT(或者文档已被同步到的其它计算装置)访问所述文档对象。此外，在链接中可以引用另外/备选的云站点，以致通过引用的云站点也可访问该文档或其它资源。

这里，值得注意的是云中的文件夹和文件，和本地文件系统中的文件夹和文件可能表现出稍微不同的特性。现在参见图4d，图中表示了包括将用于说明这些特性中的一些特性的许多文件夹和文件的例证云文件系统和例证SyncCLIENT文件系统。

具体地，图4d中描述的例证云文件系统表现出“自下而上”结构，而不是本领域的技术人员易于认识的客户端文件系统的“自上而下”结构。更具体地，云文件系统表现出的这种“自下而上”结构结果形成属于单个文件的多个文件夹。

如图4d中所示，可观察到单个文件(FILE A)属于文件夹BAZ(或者包含在文件夹BAZ内)，而文件夹BAZ又属于两个文件夹FOO和BAR。因而，电子保存在云中的文件可具有多个父文件夹，而父文件夹又可具有多个父文件夹。在这点上，文件夹类似于应用于文件的标签。

此外，如在云中使用的一样，文件夹和/或文件的名称通常不是唯一的。因而，更准确地说，名称被视为文件和文件夹的标题属性。从而，并且如在本领域中的其它地方所述，云中的文件和文件夹具有唯一的标识符，资源ID(resourcelD)，所述resourcelD唯一地识别它与之相关的文件或文件夹。

可认识到，文件和/或文件夹的本地名称可不同于其在云中的名称，因为可能与本地文件系统中具有相同名称的其它文件/文件夹存在冲突。在子代之间和在父代之间都可能发生这种冲突。从而，在例证实施例中，按照本公开的一个方面，在文件夹resourcelD及其名称(在云中)与其当电子保存在SyncCLIENT上时的本地名称之间，进行映射。

图4d中描述了云文件夹/文件和本地文件夹/文件之间的例证映射。在例证实施例中，可通过FileMapping对象实现这种映射，FileMapping对象包括一个或多个LocalEntry对象和一CloudEntry对象。如图4d中所示，本地文件夹FOO被映射到云文件夹FOO，本地文件夹BAR被映射到云文件夹BAR，两个本地文件夹BAZ被映射到单个云文件夹BAZ，两个FILE A文件被映射到单个云文件，FILE A。

图4e描述按照本公开的各个方面，当文件/文件夹被保存在云存储系统中时，文件/文件夹之间的差异，和这些差异如何影响共享/同步的另一个例子。参见图4e，图中在云文件系统中，描述了名为FOO的文件夹，它具有都命名为BAR的两个子文件夹。从而，并且按照本公开的一个方面，当在本地文件系统上复制/同步重复的文件夹BAR时，利用云资源的创建日期，唯一地命名它们。如在图4e的例子中所示，一个文件夹在本地文件系统中被命名为BAR，而另一个文件夹被命名为BAR[XX/XX/XX]，其中XX/XX/XX是该文件夹的云资源的创建日期。

图4f描述按照本公开的各个方面，当文件/文件夹被保存在云存储系统中时，文件/文件夹之间的差异，和这些差异如何影响共享/同步的另一个例子。参见图4f，图中再次在云文件系统中，描述了名为FOO的文件夹，它具有都命名为BAR的两个子文件夹。从而，并且按照本公开的一个方面，当在本地文件系统上复制/同步重复的文件夹BAR时，在这个例子中，利用递增计数器唯一地命名它们。如在图4f的例子中所示，在本地文件系统中，一个文件夹被命名为BAR[n]，而另一个文件夹被命名为BAR[n+1]。本领域的技术人员会认识到本公开可构思出这种递增计数方法和在前述段落中说明的云对象的创建日期的组合。

最后，现在参见图4g，图中表示电子保存在云文件系统中，并且与3个独立的文件夹，即，FOO、BAR和BAZ相关(包含在其中)的单个特定文件，File A的同步的示意图。特别地，当该File A被复制/与SyncCLIENT同步，并且被电子保存在该客户端上的本地文件系统中时，在SyncCLIENT文件系统上创建3个单独的文件夹，即，FOO、BAR和BAZ，其中每个文件夹包含复制的File A的独立副本。有利的是，当这3个文件任意之一被本地修改时，对于存在于云文件系统中的对应单个File A，随后发生与云的同步。

现在参见图5，图中表示了可例证地进行前面参考图1-4说明的操作的SyncCLIENT510的示意方框图500。如图5中所示，例证的SyncCLIENT包括云观察器540、本地观察器(即，类型2观察器530或类型1观察器535)、事件聚合器561、抓取器580、工作器590、快照560和黑名单570。

如前所述，云观察器540监视和检测对云文件系统520的任何有关变更，而本地观察器(530或535)监视和检测对所观察的本地文件系统515的任何变更。就云观察器540来说，如果检测到对云文件系统520的任何有关变更，那么这些检测到变更的FSChange通知被发送给抓取器580。就本地观察器(530或535)来说，如果检测到任何本地文件系统变更，那么向事件聚合器561发送通知。

按照本公开的一个方面，事件聚合器561酌情接收来自本地观察器(类型-1)535或者来自本地观察器(类型-2)530的变更通知。在优选实施例中，本地观察器(类型-1)535向事件聚合器561提供原始事件文件级变更通知，而本地观察器(类型-2)530向事件聚合器561提供FSChange通知。

尽管将在后面更详细地说明事件聚合器561的操作，不过，我们特别指出事件聚合器561一般接收来自观察器的变更通知，并把这些通知保留一段时间。如果在保留期间，对任何相关项目作出多个变更，那么有利的是，事件聚合器561将把这些变更组合或以其它方式修改成更高级、更相干的事件，所述更高级、更相干的事件随后由事件聚合器561发送给抓取器580。

由云观察器540或事件聚合器561发送给抓取器580的FSChange项目由抓取器80接收，抓取器80随后检查，以了解接收的任意变更是否被包含在黑名单570中。黑名单570是列举先前已被发送给工作器590，但是由于一个或另一个原因而未被完成的那些变更的结构。因而，黑名单570起将不被执行的变更的列表的作用，只要这些变更留在黑名单570上。

相反，抓取器580接收的未被包含在黑名单570中的变更，由抓取器550作为工作项目发送给工作器590，以便随后处理。如果工作器不能完成工作项目，那么声明错误597，并向黑名单570追加错误的记录。相反，当工作器完成工作项目时，在快照560中指示作为结果的任何变更，如前所述，快照560保持SyncCLIENT 510观察的本地文件系统515和云文件系统520之间的当前同步状态。

本领域的技术人员通常会认识到，工作项目通常是为了实现FSChange，而由工作器进行的那些操作。更具体地，特定的工作项目通常识别它适用于的对象(即，文件名)，指令(即，下载/上传)，和诸如创建、重命名、删除、移动和修改之类的操作。

如图5中所示，当工作器590对快照560作出任何变更/更新时，快照560被锁定。这种锁定确保在更新期间，快照560不会变更，从而确保一致性。

如图中所示和更详细所述，抓取器550通常在工作器590的后续并行处理之前，使工作项目流串行化。在这方面，并且如下详细所述，抓取器起确保没有任何两个工作器作用于冲突和/或重叠的变更的管理器/锁定器的作用。

本领域的技术人员会认识到，存在例证的SyncCLIENT 510软件可在上面运行的许多不同操作系统。这种操作系统的公知例子包括(但不限于)：Microsoft WINDOWS、OS/X和LINUX。作为这种操作系统的能力的结果，工作器590可被实现成多个线程。从而，多个工作器可同时在多处理器或多核计算系统上工作，或者可并行地在单处理器计算系统上工作。结果，多个工作器可彼此同时地处理给定的工作项目，从而增强共享和同步操作的性能。

不同的操作系统，比如上面列举的那些操作系统提供关于在存在于所述系统中的文件系统内可能发生的变化的不同程度的细节。例如，UNIX衍生物，比如OS/X和LINUX提供文件夹级变更通知，而Microsoft WINDOWS提供更详细的文件级变更通知。更具体地，OS/X提供关于对文件夹作出的变更的信息，而Microsoft WINDOWS提供关于对各个文件夹作出的变更的信息。从而在图5中描述至少两个不同的本地观察器，即，本地观察器(类型-2)530和本地观察器(类型-1)531。如图5中进一步所示，本地观察器(类型-2)提供文件夹级变更通知531，而本地观察器(类型-1)535提供文件级变更通知536。

更具体地，Microsoft WINDOWS提供ReadDirectoryChangesW应用编程接口(API)，所述API向访问该API的SyncCLIENT软件提供例如以下通知：CHANGE_FILE_NAME–观察的文件夹(目录)或子树中的任意文件名变更；CHANGE_DIR_NAME-观察的目录或子树中的任何目录名变更；CHANGE_ATTRIBUTES-观察的目录中的任何属性变更；CHANGE_SIZE-当写入文件时，观察的目录或子树中的任何文件大小变更；CHANGE_LAST_ACCESS-对观察的目录或子树中的文件的最后访问时间的任何变更；CHANGE_CREATION-对观察的目录或子树中的文件的创键时间的任何变更；和CHANGE_SECURITY-观察的目录或子树中的任何安全描述符变更。

由于OS X不提供这种文件级变更通知，因此本地观察器(类型-2)530利用本地图532跟踪所观察的本地文件系统515的状态。类似地，并且按照本公开的一个方面，云观察器540利用云图541跟踪被观察的云文件系统520的状态。

最后，这里我们指出，尽管图5把本地观察器(类型-2)530和本地观察器(类型-1)535描述成SyncCLIENT 510的组成部分，不过，有利的是，SyncCLIENT的特定例示并不需要这两者。

现在参见图5a，图中表示说明与电子保存文件“N”的存储，以及本地观察器535和事件聚合器561的操作相关的事件的序列的示意方框图。本领域的技术人员会认识到，这种序列可伴随任意的许多通用应用程序或程序套件的操作。

更具体地，在存储电子保存文件“N”时，与这些通用应用程序或程序套件相关的事件的一般序列是：

1)创建临时文件“N+l”；

2)删除文件“N”；

3)把临时文件“N+1”移动到“N”。

因而，在SyncCLIENT操作期间，所观察的本地文件系统515将表现出将由本地观察器535检测的以上事件序列。如果该序列将由本地观察器535转发给抓取器(未具体图示)，那么会进行许多不必要的步骤，而这可能会不利地影响系统的性能。为了保持性能和避免不必要/冗余的步骤，按照本公开的另一个方面，例证的SyncCLIENT包括事件聚合器561。

如前所述，事件聚合器561通常将接收来自本地观察器的变更通知，并把这些通知保留一段时间。如果在保留期间，对任何相关的项目作出多个变更，那么有利的是，事件聚合器561将把这些变更组合或以其它方式修改成更高级、更相干的事件，所述更高级、更相干的事件随后由事件聚合器561发送给抓取器。

继续参见图5a，事件聚合器561被描述成接收事件的上述序列，即，1)创建临时文件N+1；2)删除文件N；和3)把临时文件N+1移动到N。如在图5a中所示，事件聚合器561把该序列保持和聚合/组合成单一的工作项目，即：

“Modify(N->N+1)”；

该工作项目随后被转发给抓取器，以便处理。

图5b是说明按照本公开的一个方面，事件聚合器561的处理的概况的示意图。如图5b中所示，本地观察器535在所观察的本地文件系统515中检测到的变更事件被发送给事件聚合器561，在事件聚合器561，所述变更事件被放入变更事件队列中。

在把接收的变更事件插入变更事件队列中之前，检查接收的变更事件，以了解接收的变更事件是否能够与已在变更事件队列中的变更事件组合。如果是，那么组合接收的变更事件和变更事件队列中的变更事件，随后把组合的变更事件重新插入变更事件队列中。如果接收的变更事件不能与已在变更事件队列中的变更事件组合，那么不组合地把接收的变更事件插入变更事件队列中。

定期地，检查变更事件队列，在变更事件队列中达到预定一段时间的任何变更事件被分派给抓取器(未具体图示)，以便处理。

图5c是说明按照本公开的一个方面的事件聚合器561的一般操作概况的流程图。参见图5c，注意在方框562，事件聚合器561接收来自本地观察器的变更事件。当收到变更事件时，在方框563，事件聚合器将检查接收的变更事件，以判定接收的变更事件是否可以与已插入变更事件队列中的另一个接收的变更事件组合。

如果接收的变更事件可以与已在变更事件队列中的变更事件组合，那么在方框564，组合接收的变更事件和排队的变更事件，在方框565，把组合后的变更事件排入变更事件队列中。

如果在方框564，接收的变更事件不能与排队的变更事件组合，那么在方框565，把接收的变更事件不组合地排入变更事件队列中。

定期地，在方框566，检查变更事件队列，以判定任何排队的变更事件已持续大于预定时期的一段时间在变更事件队列中。如果是，那么在方框567，使该变更事件出列，并发送给抓取器，以便处理。

特别地，并且按照本公开的另一个方面，事件聚合器561可根据可识别的已知/学习的模式，组合接收的事件和已在事件队列中的事件。更具体地，事件聚合器可根据接收的变更序列、观察的文件种类，检测的可执行程序，执行进程等的已知模式，识别特定的事件组合，并根据这些数据确定观察的特定变更，和利用该信息进行组合。

现在参见图6，图中表示描述按照本公开的一个方面，在典型的SyncCLIENT 610上的云观察器640和本地观察器(类型-2)630的操作的示意方框图。如图6中所示，云观察器640生成云图642，云图642表示被观察的云文件系统680的当前状态。在生成云图642之后，云观察器640定期生成当前云状态表现644，随后确定这两者之间的任何差异。当检测到云图642和当前云状态表现644之间的差异时，云观察器640生成FSChange(文件系统变更通知)，并把该FSChange发送给抓取器(未具体图示)。如前关于图5所述，FSChange通知被抓取器用于生成待发送给工作器(未具体图示)的工作项目。

在优选实施例中，当前云状态表现644可用向SyncCLlENT报告的对云文件系统内的对象作出的变更的有序列表表示。最好，云图642可被表示成目录结构，所述目录结构包括ResourcelD关键字，其中除了ResourcelD之外，词典条目还包括任何文件名、检查和、以及时间戳。

类似地，本地观察器(类型-2)630通过例如FSEvents API，监视所观察的本地文件系统615，FSEvents API提供文件夹级变更通知。当收到任何文件夹级变更通知时，本地观察器(类型-2)630生成表示所观察的本地文件系统615的当前状态的当前本地状态表现634。本地观察器(类型-2)630比较当前本地状态表现634和以前生成的本地图632，以确定这两者之间的任何差异。当检测到当前本地状态表现634和本地图632之间的差异时，本地观察器630生成FSChange，并把该FSChange发送给事件聚合器(未具体图示)。如前参考图5a和图5b所述，事件聚合器把变更保持一段时间，如果检测到对相关项目或特定的已知模式的多个变更，那么事件聚合器可把这些接收的FSChange事件组合或以其它方式修改成更高级的相干事件，所述更高级的相干事件随后作为待进行的工作项目被发送给抓取器。

图6a是描述当前云状态644的接收和更新的示意方框图。如图6a中所示，根据SyncCLlENT 610从云接收的变更日志646，确定当前云状态644。在例证实施例中，如图6a中所示的变更日志646包括对与特定SyncCLlENT 610和/或特定账户相关的云文件系统680作出的变更的有序列表。

有利地，并且按照本公开的一个方面，当被SyncCLlENT 610接收时，包含在变更日志646中的对云文件系统680作出的变更的有序列表已被聚合。从而，借助变更日志646，从云文件系统接收的变更的有序列表不需要像前面所述，对本地观察器观察到的变更进行的聚合一样的进一步聚合。

在特殊的例证实施例中，对于特定账户，变更日志646包括许多条目，所述许多条目包括项目的当前状态的指示；条目是否已被移动到垃圾箱；和条目是否已从垃圾箱被删除。注意，包含在变更日志中的条目的该例证列表是代表性的，并不是详尽的。从而，借助变更日志，可以提供指示项目的状态的其它条目。本领域的技术人员会认识到，变更日志中的这些条目可被云观察器用于生成将被转发给抓取器的FSChange事件。

现在参见图7，图中表示按照本公开的一个方面，说明典型的SyncCLIENT 710进行的工作项目的生成和这些工作项目的后续处理的示意方框图。如图中所示和前面所述，一个或多个FSCHange事件作为工作项目，从云观察器740或事件聚合器735被发送给抓取器720，在抓取器720，它们被放入有序的工作队列726中。

更具体地，当收到工作项目725时，抓取器720排列接收的工作项目725，以致按照规定的顺序执行它们。更具体地，工作项目725[1]...725[n]被输入从最老的项目到最新的项目排序的工作队列726中。在这点上，通过工作队列726的实现，在把工作项目725[1]...725[n]分配给工作器750[1]...750[n]之前，抓取器720可以使这些工作项目串行化，以便同时处理。

此时，我们再次指出，尽管我们把工作器750[1]...750[n]进行的工作项目的处理描述成是同时进行的，不过在当代计算系统中可能存在的多处理器或多核处理配置中，有利的是可并行地进行多个工作器750[1]...750[n]的多个工作项目的实际处理，其中每个工作器线程可由单个处理器或核芯执行。因而，当同时或并行工作时，这种多工作器配置实现相当大的共享和同步吞吐量。有利的是，取决于SyncCLIENT710采用的特定计算系统硬件和系统软件，作为云观察器740和本地观察器730同时或并行工作的结果，实现类似的性能益处。

现在参见图8，图中表示说明抓取器820的工作项目825[1]...825[n]的串行化。如图中所示，按照从最老的工作项目到最新的工作项目的顺序，在工作队列826中排列到来的工作项目825[1]...825[n]。

操作上，抓取器820检查工作队列826中的每个工作项目，并判定它是否可由工作器850[1]...850[n]处理。在图8中所示的例证实施例中，抓取器820从最老的工作项目开始，朝着最新的工作项目前进地检查工作队列826中的工作项目825[1]...825[n]，以确定所检测的特定工作项目表现出什么依赖(如果有的话)。如果工作队列826中的被检查工作项目825[1]...825[n]受依赖图890中的任何条目影响，那么该工作项目被确定为在当时是不可处理的。

如图8中所示，依赖图890包括在给定时间可能受多个工作器850[1]...850[n]任意之一进行的操作影响的结构的列表。在图8中描述的特别重要的依赖图890条目是：索引节点(inode)891、资源ID 892和文件名等893。未在图8中具体示出的另外的依赖包括父对象、子对象和表亲对象的文件名。

本领域的技术人员易于想起，索引节点是当代操作系统用于保存关于文件、目录或其它文件系统对象的信息的数据结构。索引节点保存关于文件和目录(文件夹)的信息，比如所有者、模式和类型。文件与利用整数(索引节点号)识别的特定索引节点关联。

类似地，resourcelD是唯一地识别云对象(例如文件)的标识符。因而，这样的resourcelD会唯一地识别保存在云文件系统内的特定文件。

最后，文件名通常是关于文件的元数据。文件名常常是用于识别(最好唯一地)电子保存在文件系统中的文件的字符串。时常地，文件名包括另外的组成，即，与文件相关的路径，与文件相关的名称，与文件相关的类型，和与文件相关的版本。

有利地，并且按照本公开的一个方面，抓取器820保持依赖图890，依赖图890识别目前受任意工作器850[1]...850[n]作用于的工作项目影响的依赖。因而，当抓取器820检查工作队列826中的工作项目825[1]...825[n]时，它比较受所检查的工作项目影响的依赖和依赖图890中的任何依赖。如果受所检测的工作项目影响的任何这种依赖在依赖图890中，那么该工作项目被跳过，抓取器820检查工作队列826中的下一个工作项目。

特别地，即使特定的工作项目被跳过，最好也维持工作项目825[1]...825[n]的排序。因而，抓取器820内的工作队列826总是按从最老的工作项目到最新的工作项目的顺序。

如果确定特定工作项目是可处理的，即，其受影响的依赖不在依赖图890中，那么该工作项目被传给工作器850[1]...850[n]，以便处理。

每当工作项目被转到工作器以便处理时，就在依赖图890中指示任何受影响的依赖。相反，每当工作器完成工作项目时，它就更新依赖图890，以指示它不再处理特定的一组依赖。

每当工作器完成特定的工作项目，抓取器820就从工作队列820中最老的工作项目825[1]开始，扫描到工作队列826中最新的工作项目825[n]地重新检查工作队列820。

本领域的技术人员易于理解，工作队列826中的先前被跳过的工作项目(例如归因于依赖冲突)将被重新扫描和处理，如果抓取器820作出这样的决定的话。更有利的是，由于抓取器820确保发送给工作器的两个工作项目不存在依赖冲突，因此不需要锁定，从而在工作器操作中实现高度的同时性和/或并行性。

图9表示适合于实现按照本公开的一个方面的方法和系统的例证计算机系统900。计算机系统可包含例如运行许多操作系统任意之一的计算机。可作为保存的程序控制指令的形式，在计算机系统900上实现本公开的上述方法。

计算机系统900包括处理器910、存储器920、存储装置930和输入/输出结构940。一个或多个输入/输出装置可包括显示器945。一条或多条总线950一般互连组件910、920、930和940。处理器910可以是单核或多核。

处理器910执行其中本公开的实施例可包含在一个或多个附图中说明的步骤的指令。这样的指令可被保存在存储器920或存储装置930中。利用一个或多个输入/输出装置，可以接收和输出数据和/或信息。

存储器920可保存数据，可以是计算机可读介质，比如易失性或非易失性存储器。存储装置930可为系统900提供存储，例如包括前述方法。在各个方面，存储装置930可以是采用磁、光、或其它记录技术的闪存装置、磁盘驱动器、光盘装置或磁带装置。

输入/输出结构940可为系统900提供输入/输出操作。利用这些结构的输入/输出装置例如可包括键盘、显示器95、指示装置和麦克风等。如图所示，并且本领域的技术人员易于认识到，供本公开使用的计算机系统900可用桌上型计算机960，膝上型计算机970，手持式计算机，例如平板计算机、个人数字助手或智能电话机980，或者有利地可包含“云”计算机990的一个或多个服务器计算机实现。

尽管利用一些具体例子，介绍了本公开，不过，本领域的技术人员会认识到我们的教导并不局限于此。因而，本公开只应由附加权利要求的范围限定。

Claims (19)

1.一种在云文件系统和客户端文件系统之间共享和同步多个电子存储的资源的方法，所述方法包括：

识别所述多个电子存储的资源，所述多个电子存储的资源被存储在所述云文件系统中并且在所述云文件系统中具有相同的名称；

在所述客户端文件系统中生成所述多个电子存储的资源中的第一资源的副本；

在所述客户端文件系统中生成所述多个电子存储的资源中的第二资源的副本；以及

通过所述客户端文件系统的处理设备利用递增计数器来命名所述多个电子存储的资源中的所述第二资源的副本，以在所述客户端文件系统中为所述多个电子存储的资源中的所述第二资源的副本创建唯一名称。

2.按照权利要求1所述的方法，还包括：

使用所述云文件系统中的所述多个电子存储的资源中的所述第一资源的名称来命名所述多个电子存储的资源中的所述第一资源的副本。

3.按照权利要求2所述的方法，其中，作为利用所述客户端文件系统对被存储在所述云文件系统中并且在所述云文件系统中具有相同的名称的所述多个电子存储的资源的同步的一部分来执行所述第一资源的副本的生成、所述第二资源的副本的生成、所述第一资源的副本的命名和所述第二资源的副本的命名。

4.按照权利要求1所述的方法，其中，所述第一资源的副本和所述第二资源的副本都包括指向相应的电子存储的资源的链接。

5.按照权利要求1所述的方法，其中，所述多个电子存储的资源包括电子存储的文件。

6.按照权利要求5所述的方法，其中，所述电子存储的文件在所述云文件系统中的多个文件夹中被共享。

7.按照权利要求6所述的方法，还包括：

在所述客户端文件系统中生成所述电子存储的文件的多个副本。

8.按照权利要求7所述的方法，其中，副本的数量等于所述多个文件夹中的文件夹的数量。

9.按照权利要求1所述的方法，其中，命名所述第二资源的副本进一步包括：

将所述第二资源在所述云文件系统中被创建的日期的标记添加到所述第二资源的副本的唯一名称。

10.按照权利要求9所述的方法，其中，所述日期包括所述第二资源在所述云文件系统中被创建的月、日和年。

11.一种包括指令的非暂时性计算机可读介质，所述指令在被客户端文件系统的处理设备执行时使得所述客户端文件系统的所述处理设备执行在云文件系统和所述客户端文件系统之间共享和同步多个电子存储的资源的操作，所述操作包括：

识别所述多个电子存储的资源，所述多个电子存储的资源被存储在所述云文件系统中并且在所述云文件系统中具有相同的名称；

在所述客户端文件系统中生成所述多个电子存储的资源中的第一资源的副本；

在所述客户端文件系统中生成所述多个电子存储的资源中的第二资源的副本；以及

利用递增计数器来命名所述多个电子存储的资源中的所述第二资源的副本，以在所述客户端文件系统中为所述多个电子存储的资源中的所述第二资源的副本创建唯一名称。

12.按照权利要求11所述的非暂时性计算机可读介质，其中，所述操作还包括：

使用所述云文件系统中的所述多个电子存储的资源中的所述第一资源的名称来命名所述多个电子存储的资源中的所述第一资源的副本。

13.按照权利要求12所述的非暂时性计算机可读介质，其中，作为利用所述客户端系统对被存储在所述云文件系统中并且在所述云文件系统中具有相同的名称的所述多个电子存储的资源的同步的一部分来执行所述第一资源的副本的生成、所述第二资源的副本的生成、所述第一资源的副本的命名和所述第二资源的副本的命名。

14.按照权利要求11所述的非暂时性计算机可读介质，其中，所述第一资源的副本和所述第二资源的副本都包括指向相应的电子存储的资源的链接。

15.按照权利要求11所述的非暂时性计算机可读介质，其中，所述多个电子存储的资源包括电子存储的文件。

16.按照权利要求15所述的非暂时性计算机可读介质，其中，所述电子存储的文件在所述云文件系统中的多个文件夹中被共享。

17.按照权利要求11所述的非暂时性计算机可读介质，其中，命名所述第二资源的副本进一步包括：

将所述第二资源在所述云文件系统中被创建的日期的标记添加到所述第二资源的副本的唯一名称。

18.一种用于在云文件系统和客户端文件系统之间共享和同步多个电子存储的资源的装置，所述装置包括：

存储器；以及

耦合到所述存储器的处理设备，用于：

识别所述多个电子存储的资源，所述多个电子存储的资源被存储在所述云文件系统中并且在所述云文件系统中具有相同的名称；

在所述客户端文件系统中生成所述多个电子存储的资源中的第一资源的副本；

在所述客户端文件系统中生成所述多个电子存储的资源中的第二资源的副本；以及

利用递增计数器来命名所述多个电子存储的资源中的所述第二资源的副本，以在所述客户端文件系统中为所述多个电子存储的资源中的所述第二资源的副本创建唯一名称。

19.按照权利要求18所述的装置，其中，所述多个电子存储的资源包括在多个文件夹中共享的电子存储的文件。

Images