US20140337290A1 - Secure synchronization of files - Google Patents

Abstract

A copy of a first file may be stored in a first instance of a file space associated with a user of a first client device. An event is generated for a first modification of the first file and the event is sent to a server. A current revision number of the file space is obtained from the server, and the current revision number is compared to a past revision number corresponding to a last time files were synchronized to the first client device. In response to a determination that the current revision number is higher than the past revision number, a number of events that have occurred to the file space are requested from the server, the number of events corresponding to a difference between the current revision number and the past revision number. The first instance of the file space is updated based on the events.

Description

CROSS-RELATION TO RELATED APPLICATIONS
• This application claims priority to U.S. Provisional Application No. 61/820,793 filed May 8, 2013, which is hereby incorporated herein by reference in its entirety.
TECHNICAL FIELD
• This application relates generally to cloud-based file storage.
• More particularly, this application relates to the secure synchronization of files stored in a cloud-based file storage.
BACKGROUND
• With the dramatic increase in use of mobile devices in recent years, it has become more important now than ever before that a user's files be synchronized between multiple devices. A single user may operate on a desktop computer, laptop computer, tablet computer, and mobile phone, editing the same document at different times on different devices. This issue is only going to become even more important as additional mobile devices, such as wearable computers and vehicle-based computers become popular mechanisms for editing files.
• Problems, however, may be encountered as the synchronization of files across devices become more complex. For example, there is an increased likelihood of file-related events occurring concurrently, such as a user editing a document on both a mobile phone and a laptop computer while his desktop computer is offline.
BRIEF DESCRIPTION OF DRAWINGS
• The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
• FIG. 1 is a block diagram illustrating a system, in accordance with an example embodiment, of securely synchronizing files.
• FIG. 2 is a block diagram illustrating a client device, in accordance with an example embodiment, in more detail.
• FIG. 3 is a block diagram illustrating another client device, in accordance with an example embodiment, in more detail.
• FIG. 4 is a block diagram illustrating a backend, in accordance with an example embodiment, in more detail.
• FIG. 5 is a diagram illustrating a system, in accordance with an example embodiment, for secure file synchronization.
• FIG. 6 is a diagram illustrating a state machine, in accordance with an example embodiment, for synchronizing a file.
• FIG. 7 is a diagram illustrating a state machine, in accordance with an example embodiment, for synchronizing a folder.
• FIG. 8 is a diagram illustrating a method, in accordance with an example embodiment, for resolution of a server-side name conflict.
• FIG. 9 is a diagram illustrating a method, in accordance with another example embodiment, for resolution of a server-side name conflict.
• FIG. 10 is a diagram illustrating a method, in accordance with another example embodiment, for resolution of a server-side name conflict.
• FIG. 11 is a diagram illustrating a method, in accordance with an example embodiment, for resolution of a client-side name conflict.
• FIG. 12 is a diagram illustrating a method, in accordance with an example embodiment, for resolution of a client-side name conflict.
• FIG. 13 is a flow diagram illustrating a method, in accordance with an example embodiment, of name conflict resolution.
• FIG. 14 is a flow diagram illustrating a method, in accordance with an example embodiment, of synchronizing a file across multiple client devices.
• FIG. 15 is a block diagram illustrating a mobile device, according to an example embodiment.
• FIG. 16 is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed.
DETAILED DESCRIPTIONOverview
• The description that follows includes illustrative systems, methods, techniques, instruction sequences, and machine-readable media (e.g., computing machine program products) that embody illustrative embodiments. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail.
• In an example embodiment, various techniques are utilized in order to allow for efficient, accurate, and secure synchronization of files across multiple devices even in cases where a large number of events are occurring concurrently. This may include using an events-based technique to improve reliability during periods of file modifications being performed concurrently. In another example embodiment, name conflicts between different files may be resolved automatically.
• FIG. 1 is a block diagram illustrating asystem100, in accordance with an example embodiment, of securely synchronizing files. In thesystem100, files may be synchronized between one ormore servers102 and one ormore client devices104A-104D. Theclient devices104A-104D may include various types of devices running various types of platforms with various types of operating systems and applications. For example,client device104A may be a mobile device running proprietarymobile applications106.Client device104B may be a personal computer running a Macintosh™ operating system from Apple Inc. of Cupertino, Calif. This may include a file system known as Finder108, which may include a specialized plug-in110 to allow Finder108 to be altered in order to better operate with aproprietary application112.
• Client device104C may be a personal computer running a Windows™ operating system from Microsoft Corp. of Redmond, Wash. This may include a file system known as Windows Explorer114, which may include a specialized plug-in116 to allow Windows Explorer114 to be altered in order to better operate with aproprietary application118. Additionally, applications such as Microsoft Office™120 and Microsoft Outlook™122 may also include their own specialized plug-ins124,126, respectively, which allow them to better operate with theproprietary application118.Client device104D may be a web-based device that may operate aweb browser128 instead of a traditional operating system.
• Each of theclient devices104A-104D may communicate with a back-end130 hosted by the one ormore servers102. This communication may either take place directly between the back-end130 and theproprietary applications106,112,118, or indirectly through aweb application132. A provisioning service, such as HostPilot™134 may also be present, and may coordinate with a directory service such asActive Directories136.
• FIG. 2 is a block diagram illustrating a client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds toclient device104C ofFIG. 1, although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components inFIG. 2 are labeled as those components are labeled inFIG. 1. In some embodiments, however, the components may not be identical.Proprietary application116 may be a desktop application, and may store files in alocal database200. Theproprietary application118 may also communicate with specialized plug-ins116,124,126 in Windows Explorer114, Microsoft Office120 and Microsoft Outlook™122, respectively. This communication may take place, for example, using Thrift over TCP. Theproprietary application118 may communicate with astorage service202 on theserver102.
• FIG. 3 is a block diagram illustrating another client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds toclient device104B ofFIG. 1, although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components inFIG. 3 are labeled as those components are labeled inFIG. 1. In some embodiments, however, the components may not be identical.Proprietary application112 may be a desktop application, and may store files in alocal database300. Theproprietary application112 may also communicate with aspecialized plugin108 in Finder110. This communication may take place, for example, using Thrift over TCP. Theproprietary application118 may communicate with astorage device302 on theserver102.
• FIG. 4 is a block diagram illustrating a backend, in accordance with an example embodiment, in more detail. In an example embodiment, the backend in this figure corresponds to backend130 ofFIG. 1, although in some example embodiments this diagram corresponds to a different backend. Additionally, the various components inFIG. 4 are labeled as those components are labeled inFIG. 1. In some embodiments, however, the components may not be identical. Thebackend130 may include a front-end server400, which acts to perform much of the server-side storage functions described in this disclosure, as well as interfacing with the various devices. These functions will be discussed in more detail later in this document. The front-end server400 may interface withclient devices104A-104D through afirewall402. The front-end server400 may also interface with adatabase server404, which may control access to adatabase406. Thedatabase406 may be of many different types of formats. In one example embodiment, thedatabase406 is a relational database, such as one operated using Structured Query Language (SQL). Other formats of database are envisioned, however, as well, including flat-file and multidimensional databases. The database may store not just files and folders, but also metadata about the files and folders, including, but not limited to, information about which files and folders are shared, and with whom.
• Acentral server408 performs internal tasks such as cleanup, provisioning, and other backend services. Akey management server410 provides access for keys created for each user. When a user is created on thecentral server408, a key may be issued by thekey server410. These keys are also used by anencryption server412 to encrypt and decrypt files and folders. This is accomplished through the use of thefront end server400, which understands which organization the keys belong and submits file or folder content to theencryption server412 for encryption.Active Directories414 is used for integration with Exchange™
File System
• In an example embodiment, when a user saves some content by /some/path/to/file, the system may assume that it is a new version of file /some/path/to/file. All versions may be stored separately. Metadata stored for the content may allow the system to retrieve file content of past versions, as well as show various attributes of a file version, such as its author, when it was created, its size, etc. In this manner, the file system can act as a symbiosis of a file system, a source versioning system and a sharing service.
• In an example embodiment, a specialized technique for determining a file name (as saved to disk) is utilized. This technique may be used anytime a file needs to be saved or retrieved. This technique involves calculating a hashsum of the file content, and then building a path using the first two characters of the hashsum as a parent folder and the next two characters of the hashsum as a subfolder. The entire hashsum may then be used as the file name within the subfolder. For example, a path may be built as: <root>/<1,2 chars of the hashsum>/<3,4 chars of the hashsum>/<hashsum> and save content there.
• As an example, a particular file may have a hashsum of “1234c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7 852b855”. The file will be saved to <root>/12/34/1234c44298fc1c149afbf4c8996fb92427ae41e4649b93 4ca495991b7852b855
• The hashsum created may also be referred to as a hashsum string. The values of particular characters of the hashsum string may be referred to as being in specific hashsum string character places (e.g., the first character of the string is in the first hashsum string character place).
• This technique allows the system to scale a large number of files folded into a set of directories, and implement de-duplication on file level content.
Events Model
• In an example embodiment, every event that has happened to an object (file/folder/permission/etc.) can be stored. For example if a file was modified, or shared with a new user, or a folder deleted, these events can all be tracked. An API may then be provided for clients to retrieve events starting from a particular number. This allows for reliable and effective retrieval of event by clients. The user is able to easily see a list of all events for a particular object, as well as details about each event. In this way, an administrator, for example, may see everyone who accessed a particular file and made edits.
• A file space may be defined as a set of files and folders owned by one user, along with links to folders shared by other users to this user. A revision may be defined as a natural number which describes current state of a file space. It is a counter of events happened in a file space.
• The file space may be stored on a server, replicated to desktop applications, and can be accessed from mobile and web apps. File spaces can be—globally and uniquely identified by path that contains user id.
• Each file space may have a number assigned to it, called a revision. In an example embodiment, the revision may be set to 1 when file space is first created, and is incremented on server every time file space changes (that is file, folder or permission is created, deleted or updated).
• Once installed, a client can retrieve from the server the list of all events for all file spaces configured starting from 0.
• In an example embodiment, when the client is started the first time, it does not retrieve a list of all events starting from revision 0, because there may be a huge number of events generated since the time the file space was created. In this case, the client can retrieve a list of all file space objects with their metadata. The server also returns the current file space revision to that request. After that initial request, the client periodically queries the server for new events as described above.
• On the next attempt to update information the client would ask server to give all events starting from revision Rw, where Rw is the highest revision number (R) received from server on last update for a particular file space (w).
File Synchronization
• FIG. 5 is a diagram illustrating a system, in accordance with an example embodiment, for secure file synchronization. Thesystem500 may include aworkstation502 and acloud504. Theworkstation502 may include alocal indexer506, which scans alocal file system508 to determine file and folder metadata and reports it to anitem manager510. Aserver indexer512 retrieves folder and file metadata from astorage service514 on thecloud504 and reports it to theitem manager510. Theserver indexer512 may periodically query thestorage service514 for changes on the cloud-side.
• The item manager may store folder and file metadata from thelocal indexer504 and theserver indexer512, calculate the state of file/folders, and asynchronously update ametadata database516. The metadata database persistently stores local and server item metadata so that it would be available after the application is closed and reopened. Synchronization rules518 are used to select files/folders that should be synchronized from theitem manager510 and creates tasks for520 such synchronization. The tasks actually perform the file and folder synchronization, including, for example, uploading, downloading, creating, deleting, etc., resulting in synchronization between thelocal file system508 and thestorage service514.
• The revision is used by a client application to get file space metadata updates from the server. If client and server revisions are equal, then the client has the same metadata as the server for this file space. If the server revision is greater, then client requests a list of file space changes, starting from the revision that it knows. These changes are represented by events that contain updated metadata for files, folders and permissions.
• The client application may store file space metadata in a local database, so that it would be available after application is restarted.
• Using revisions in conjunction with storing file space metadata locally improves synchronization performance and reduces network traffic, because, after initial synchronization, the client application queries the server only for changes in file space, and not for the whole file space metadata.
• Items (files and folders), can have several states. When an item is in the synced state, it means that this item is exactly the same on the server and on the client, and no further actions are needed for this item.
• The client application contains rules that define what actions are needed to bring every item in the file space into synced state, based on its current conditions. In an example embodiment, these rules may include the following:
• • Synced file is modified locally
    • If the file has not been modified on the server after the last synchronization, the local version will be uploaded to the server.
    • If the file has been modified on the server after the last synchronization and the server version differs from the local version, there is a synchronization conflict
    • If the file has been modified on the server after the last synchronization and the server version is the same as the local version, the file will be marked as synced.
  • Non-synced file is created or modified locally
    • If the file doesn't exist on the server, the file will be uploaded to the server.
    • If the file exists on the server and the server version differs from the local version, there is a synchronization conflict.
    • If the file exists on the server and the server version is the same as the local version, the file will be marked as synced.
  • Synced file is deleted locally
    • If the file has not been modified on the server after the last synchronization, the file will be deleted from the server.
    • If the file has been modified on the server after the last synchronization, the server version will be downloaded to the client machine.
  • Non-synced file is deleted locally
    • If the file exists on the server, the file will be downloaded to the client machine.
  • New folder is created locally
    • If the folder doesn't exist on the server, the folder will be created on the server.
  • Folder is deleted locally
    • The folder will be deleted from the server if the following conditions are met:
      • The folder exists on the server.
        • Each local file in the deleted folder (at any depth) either does not exist on the server or was synced and has not been modified on the server after the last synchronization.
        • Each server file in the deleted folder (at any depth) was synced and has not been modified on the server after the last synchronization.
        • Each server subfolder in the deleted folder (at any depth) existed locally at the moment of last synchronization.
  • Synced file is modified on the server
    • If the file has not been modified locally after the last synchronization, the server version will be downloaded to the client machine.
    • If the file has been modified locally after the last synchronization and the server version differs from the local version, there is a synchronization conflict.
    • If the file has been modified locally after the last synchronization and the server version is the same as the local version, the file will be marked as synced.
  • Non-synced file is created or modified on the server
    • If the file doesn't exist locally, the file will be downloaded to the client machine.
    • If the file exists locally and the server version differs from the local version, there is a synchronization conflict.
    • If the file exists locally and the server version is the same as the local version, the file will be marked as synced.
  • Synced file is deleted from the server
    • If the file has not been modified locally after the last synchronization, the file will be deleted locally.
    • If the file has been modified locally after the last synchronization, the local version will be uploaded to the server.
  • Non-synced file is deleted from the server
    • If the file exists locally, the file will be uploaded to the server.
  • New folder is created on the server
    • If the folder doesn't exist locally, the folder will be created locally.
  • Folder is deleted on the server
    • The folder will be deleted locally if the following conditions are met:
      • The folder exists locally.
      • Each server file in the deleted folder (at any depth) either does not exist locally or was synced and has not been modified locally after the last synchronization.
      • Each local file in the deleted folder (at any depth) was synced and has not been modified locally after the last synchronization.
      • Each local subfolder in the deleted folder (at any depth) existed on the server at the moment of last synchronization.
• FIG. 6 is a diagram illustrating a state machine, in accordance with an example embodiment, for synchronizing a file. Thesystem600 may start in a state of not being synced602. Some states, such as a determination that the system should resolve aversion conflict604 or should resolve aname conflict606 may simply cause the system to go back to the is not syncedstate602 once completed. Other states, such as a determination that the system should upload afile608, download afile610, delete locally612, or delete on aserver614 may result in the system changing to an is syncedstate616.
• FIG. 7 is a diagram illustrating a state machine, in accordance with an example embodiment, for synchronizing a folder. Thesystem700 may start in a state of not being synced702. Some states, such as a determination that the system should resolve aname conflict704 may simply cause the system to go back to the “is not synced”state702 once completed. Other states, such as a determination that the system should upload afolder706, download afolder708, delete locally710, or delete on aserver712 may result in the system changing to an is syncedstate714.
File Version Conflict Resolution
• A file version conflict may occur in the following example situations (these examples being non-exhaustive):
• • If the file has been modified locally and on the server after the last synchronization and the server version differs from the local version.
  • If the file has not been synchronized and the server version differs from the local version.
  • If the file has been modified locally after the last synchronization and the user has View permission to this file.
• In these cases, in an example embodiment, the local file is copied to the conflict file and then the local file is overwritten with the server version.
• The conflict file is created in the same folder as the original file and has the name <original file name>(Conflicted copy <YYYY-MM-DD>—for <user name>).<original file extension>(e.g. “document(Conflicted copy 2013-04-04—for Nikita Uraltsev).docx”)
Name Conflicts
• As described earlier, name conflicts can occur in various cases, including, for example:
• • Two objects of different types (file/folder/link) have the same name within a file space
  • Two links that point to different folders have the same name within a file space
• Name conflicts can be divided into two categories—server-side name conflicts and client-side name conflicts.
• A server-side name conflict occurs in the following cases:
• Case 1: The user has a file or folder named F that is located in the user's root folder on the server. Another user shares a folder named F with the first user.FIG. 8 is a diagram illustrating amethod800, in accordance with an example embodiment, for resolution of a server-side name conflict. As can be seen, a name conflict occurs in that User 1802 has aFolder F804, andUser 2806 wishes to share adifferent folder F808 with User 1802. This conflict may be resolved by creating a new folder name for User 1802 to representfolder F808. This new folder name may be thename Folder F808 with some addendum at the end, such as “(2).” This is displayed at810. Of course, there may be situations where a subsequent naming conflict creates a situation where two folders may end with the same addendum. This conflict can be avoided by incrementing a number in the addendum, such as using (3) instead of (2) for the next conflict, and so on. In other words, if the new is also in use, the number is incremented until an unused name is found.
• Case 2: The user has a temporarily deleted file or folder named F that is located in the user's root folder on the server. Another user shares a folder named F with the first user.FIG. 9 is a diagram illustrating amethod900, in accordance with another example embodiment, for resolution of a server-side name conflict. In some embodiments, when a user such as User 1902 wishes to delete a file, the file, while removed visibly from the user's directory, is not actually deleted and remains as an invisible file, allowing the user to restore the file if so desired. As can be seen, a name conflict occurs if a temporary deletedfile904 has the same name as a file or folder, such asFolder F906 thatUser 2908 wishes to share with User 1902. This conflict may be resolved by creating a new folder name for User 1902 to representfolder F906. This new folder name may be thename Folder F906 with some addendum at the end, such as (2). This is displayed at910. As with above, there may be situations where a subsequent naming conflict creates a situation where two folders may end with the same addendum. This conflict can be avoided by incrementing a number in the addendum, such as using (3) instead of (2) for the next conflict, and so on. In other words, if the new is also in use, the number is incremented until an unused name is found.
• Case 3: The user has a link named F that points to a folder shared by another user. Another user shares a different folder named F with the first user.FIG. 10 is a diagram illustrating amethod1000, in accordance with another example embodiment, for resolution of a server-side name conflict. As can be seen, a name conflict occurs if User 31002 hasFolder F1004 that he wishes to share with User 11006, while User 11006 already has afolder F1008 shared fromuser 21010. This conflict may be resolved by creating a new folder name for User 11006 to representfolder F1004. This new folder name may be thename Folder F1004 with some addendum at the end, such as (2). This is displayed at1012. As with above, there may be situations where a subsequent naming conflict creates a situation where two folders may end with the same addendum. This conflict can be avoided by incrementing a number in the addendum, such as using (3) instead of (2) for the next conflict, and so on. In other words, if the new is also in use, the number is incremented until an unused name is found.
• A client-side conflict occurs in the following cases:
• Case 4: A local file has the same name as a server folder or vice versa.FIG. 11 is a diagram illustrating amethod1100, in accordance with an example embodiment, for resolution of a client-side name conflict. Here, fileF1102 in User'sserver data1104 has a name conflict withfolder F1106 in the User'sclient data1108. This conflict may be resolved by creating a new folder name for User'sserver data1104 to representfolder F1106. This new folder name may be thename Folder F1106 with some addendum at the end, such as (2). This is displayed at1110. As with above, there may be situations where a subsequent naming conflict creates a situation where two folders may end with the same addendum. This conflict can be avoided by incrementing a number in the addendum, such as using (3) instead of (2) for the next conflict, and so on. In other words, if the new is also in use, the number is incremented until an unused name is found.
• Case 5: A local file or folder has the same name as a link to a shared folder on the server.FIG. 12 is a diagram illustrating amethod1200, in accordance with an example embodiment, for resolution of a client-side name conflict. Here, line to fileF1202 in User'sserver data1204 has a name conflict withfolder F1206 in the User'sclient data1208. This conflict may be resolved by creating a new folder name for User'sserver data1204 to representfolder F1206. This new folder name may be thename Folder F1206 with some addendum at the end, such as (2). This is displayed at1210. As with above, there may be situations where a subsequent naming conflict creates a situation where two folders may end with the same addendum. This conflict can be avoided by incrementing a number in the addendum, such as using (3) instead of (2) for the next conflict, and so on. In other words, if the new is also in use, the number is incremented until an unused name is found.
• It should be noted that in some embodiments the desktop application ensures that the local folder and shared folder are not merged. This prevents confidential data from being shared with the wrong people, even accidentally.
• FIG. 13 is a flow diagram illustrating amethod1300, in accordance with an example embodiment, of name conflict resolution. Atoperation1302, it is determined if an object (e.g., file or folder) has a name conflict. If so, then atoperation1304, it is determined if any ancestor of the object also has a name conflict. If not, then atoperation1306 it is determined if the object exists locally and does not exist on the server. If so, then synchronization of the object and its descendants is suspected atoperation1308. Then, atoperation1310, a new name X (N) is selected for a local folder X. Atoperation1312, it is determined if the name X(N) is in use. If so, then atoperation1314, N may be incremented and the process may return tooperation1310. If not, then atoperation1316, folder X may be renamed as X(N). Atoperation1318, paths for this object's and its descendants metadata may be updated, replacing X with X(N). Finally, at operation1320, synchronization for this object and its descendants may be resumed.
• FIG. 14 is a flow diagram illustrating amethod1400, in accordance with an example embodiment, of synchronizing a file across multiple client devices. Atoperation1402, a copy of a first file is stored in a first instance of a file space associated with a user of a first client device. The file space contains one or more files accessible to the user across the multiple client devices. The first instance of the file space may be located at the first client device. Atoperation1404, a first modification of the first file may be received from the user at the first client device. This may include, for example, receiving input via a user interface on the first client device, but alternatively could include automatically altering files based on a set of rules and/or based on files received from other sources (e.g., an email rule indicating that if a file with a certain file name is received via email, it should overwrite an existing file in memory).
• Atoperation1406, an event may be generated for the first modification. The event may contain various pieces of metadata. In one example embodiment, the event contains enough information so that a system could use to the event to update an older version of the first file in the same way the first modification does. For example, the event may contain the terms, phrases, sentences, formatting, etc. that has changed due to the first modification, allowing another system to replicate the same changes on their version of the first file. Atoperation1408, the event may be sent to a server. Operations1402-1408 may be repeated each time a modification occurs. Notably, while not pictured, the server, upon receipt of the event, may increment a current revision number for the file space. This may be done each time an event is received from any of the client devices.
• Atoperation1410, a current revision number of the file space may be obtained from the server. Atoperation1412, the current revision number is compared to a past revision number corresponding to a last time files were synchronized from the server to the first client device. Atoperation1414, in response to a determination that the current revision number is higher than the past revision number, a number of events that have occurred to the file space may be requested from the sever, the number of events corresponding to a difference between the current revision number and the past revision number. Atoperation1416, the events may be received. Atoperation1418, the first instance of the file space may be updated based on the events.
Example Mobile Device
• FIG. 15 is a block diagram illustrating amobile device1500, according to an example embodiment. Themobile device1500 can include a processor1502. The processor1502 can be any of a variety of different types of commercially available processors suitable for mobile devices1500 (for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor). Amemory1504, such as a random access memory (RAM), a Flash memory, or other type of memory, is typically accessible to the processor1502. Thememory1504 can be adapted to store an operating system (OS)1506, as well asapplication programs1508, such as a mobile location enabled application that can provide LBSs to a user. The processor1502 can be coupled, either directly or via appropriate intermediary hardware, to adisplay1510 and to one or more input/output (I/O)devices1512, such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor1502 can be coupled to atransceiver1514 that interfaces with anantenna1516. Thetransceiver1514 can be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via theantenna1516, depending on the nature of themobile device1500. Further, in some configurations, aGPS receiver1518 can also make use of theantenna1516 to receive GPS signals.
Modules, Components and Logic
• Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules can constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors can be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.
• In various embodiments, a hardware-implemented module can be implemented mechanically or electronically. For example, a hardware-implemented module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module can also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.
• Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor can be configured as respective different hardware-implemented modules at different times. Software can accordingly configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time.
• Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules can be regarded as being communicatively coupled. Where multiple such hardware-implemented modules exist contemporaneously, communications can be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware-implemented modules. In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules can be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module can then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules can also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
• The various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein can, in some example embodiments, comprise processor-implemented modules.
• Similarly, the methods described herein can be at least partially processor-implemented. For example, at least some of the operations of a method can be performed by one of processors or processor-implemented modules. The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors can be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors can be distributed across a number of locations.
• The one or more processors can also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)
Electronic Apparatus and System
• Example embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments can be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
• A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
• In example embodiments, operations can be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments can be implemented as, special purpose logic circuitry, e.g., a FPGA or an ASIC.
• The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware can be a design choice. Below are set out hardware (e.g., machine) and software architectures that can be deployed, in various example embodiments.
Example Machine Architecture and Machine-Readable Medium
• FIG. 16 is a block diagram of machine in the example form of a computer system1600 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
• The example computer system1600 includes a processor1602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory1604 and a static memory1606, which communicate with each other via a bus1608. The computer system1600 can further include a video display unit1610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system1600 also includes an alpha-numeric input device1612 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation device1614 (e.g., a mouse), a disk drive unit1616, a signal generation device1618 (e.g., a speaker), and a network interface device1620.
Machine-Readable Medium
• The disk drive unit1616 includes a machine-readable medium1622 on which is stored one or more sets of instructions and data structures (e.g., software)1624 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions1624 can also reside, completely or at least partially, within the main memory1604 and/or within the processor1602 during execution thereof by the computer system1600, with the main memory1604 and the processor1602 also constituting machine-readable media1622.
• While the machine-readable medium1622 is shown in an example embodiment to be a single medium, the term “machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures1624. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions1624 for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions1624. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media1622 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
Transmission Medium
• The instructions1624 can further be transmitted or received over a communications network1626 using a transmission medium. The instructions1624 can be transmitted using the network interface device1620 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions1624 for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
• Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter can be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments can be utilized and derived therefrom, such that structural and logical substitutions and changes can be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
• Such embodiments of the inventive subject matter can be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose can be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims (20)

1. A method of synchronizing a file across multiple client devices, the method comprising:

storing a copy of a first file in a first instance of a file space associated with a user of a first client device, the file space containing one or more files accessible to the user across the multiple client devices, the first instance of the file space located at the first client device;

receiving, from the user, at the first client device, a first modification of the first file;

generating an event for the first modification;

sending the event to a server;

obtaining a current revision number of the file space from the server;

comparing the current revision number to a past revision number corresponding to a last time files were synchronized from the server to the first client device;

in response to a determination that the current revision number is higher than the past revision number, requesting a number of events that have occurred to the file space from the sever, the number of events corresponding to a difference between the current revision number and the past revision number;

receiving the events; and

updating the first instance of the file space based on the events.

2. The method ofclaim 1, wherein the storing comprises:

performing a hashsum on the copy of the first file, producing a hashsum string having a value in each of a plurality of hashsum string character places; and

storing the copy of the first file in a parent folder having a name matching a string comprising the value in a first two hashsum string character places in the hashsum string, and in a subfolder within the parent folder, the subfolder having a name matching a string comprising the value in a second two hashsum string character places in the hashsum string.

3. The method ofclaim 1, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to an existing object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

4. The method ofclaim 3, wherein the automatically renaming includes adding an addendum to a name of the new object.

5. The method ofclaim 1, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to a recently deleted object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

6. The method ofclaim 1, wherein the updating the first instance of the file space comprises:

determining a first folder exists in the first instance of the file space that has an identical name to a second folder in a second instance of the file space on a second client device, the second folder in the second instance of the file space being shared with the user of the first client device; and

automatically renaming an instance of the second folder prior to it being stored in the first instance of the file space.

7. The method ofclaim 1, wherein the updating the first instance of the file space comprises:

determining a first folder exists in the first instance of the file space that has an identical name to a link in a second instance of the file space on a server; and

automatically creating a new folder in the second instance of the file space on the server, the new folder corresponding to the first folder.

8. A system comprising:

one or more processors;

a memory storing a first instance of a file space;

a local indexer executable by the one or more processors and configured to:

store a copy of a first file in the first instance of a file space associated with a user of a first client device, the file space containing one or more files accessible to the user across the multiple client devices;

an item manager configured to:

receive, from the user, a first modification of the first file; and

generate an event for the first modification according to one or more synchronization rules;

a server indexer configured to:

send the event to a server;

the item manager further configured to:

obtain a current revision number of the file space from the server;

compare the current revision number to a past revision number corresponding to a last time files were synchronized from the server to the first client device, according to the one or more synchronization rules, the last time files were synchronized being stored in a metadata database;

in response to a determination that the current revision number is higher than the past revision number, reques a number of events that have occurred to the file space from the sever, the number of events corresponding to a difference between the current revision number and the past revision number; and

receive the events; and

the local indexer further configured to update the first instance of the file space based on the events.

9. The system ofclaim 8, wherein the storing comprises:

performing a hashsum on the copy of the first file, producing a hashsum string having a value in each of a plurality of hashsum string character places; and

storing the copy of the first file in a parent folder having a name matching a string comprising the value in a first two hashsum string character places in the hashsum string, and in a subfolder within the parent folder, the subfolder having a name matching a string comprising the value in a second two hashsum string character places in the hashsum string.

10. The system ofclaim 8, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to an existing object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

11. The system ofclaim 10, wherein the automatically renaming includes adding an addendum to a name of the new object.

12. The system ofclaim 8, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to a recently deleted object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

13. The system ofclaim 8, wherein the updating the first instance of the file space comprises:

determining a first folder exists in the first instance of the file space that has an identical name to a second folder in a second instance of the file space on a second client device, the second folder in the second instance of the file space being shared with the user of the first client device; and

automatically renaming an instance of the second folder prior to it being stored in the first instance of the file space.

14. The system ofclaim 8, wherein the updating the first instance of the file space comprises:

determining a first folder exists in the first instance of the file space that has an identical name to a link in a second instance of the file space on a server; and

automatically creating a new folder in the second instance of the file space on the server, the new folder corresponding to the first folder.

15. A non-transitory machine-readable storage medium comprising instructions, which when implemented by one or more machines, cause the one or more machines to perform operations comprising:

storing a copy of a first file in a first instance of a file space associated with a user of a first client device, the file space containing one or more files accessible to the user across multiple client devices, the first instance of the file space located at the first client device;

receiving, from the user, at the first client device, a first modification of the first file;

generating an event for the first modification;

sending the event to a server;

obtaining a current revision number of the file space from the server;

comparing the current revision number to a past revision number corresponding to a last time files were synchronized from the server to the first client device;

in response to a determination that the current revision number is higher than the past revision number, requesting a number of events that have occurred to the file space from the sever, the number of events corresponding to a difference between the current revision number and the past revision number;

receiving the events; and

updating the first instance of the file space based on the events.

16. The non-transitory machine-readable storage medium ofclaim 15, wherein the storing comprises:

performing a hashsum on the copy of the first file, producing a hashsum string having a value in each of a plurality of hashsum string character places; and

storing the copy of the first file in a parent folder having a name matching a string comprising the value in a first two hashsum string character places in the hashsum string, and in a subfolder within the parent folder, the subfolder having a name matching a string comprising the value in a second two hashsum string character places in the hashsum string.

17. The non-transitory machine-readable storage medium ofclaim 15, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to an existing object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

18. The non-transitory machine-readable storage medium ofclaim 17, wherein the automatically renaming includes adding an addendum to a name of the new object.

19. The non-transitory machine-readable storage medium ofclaim 15, wherein the updating the first instance of the file space comprises:

determining that a new object in the file space has an identical name to a recently deleted object in the first instance of the file space; and

automatically renaming the new object as a variation on the identical name in response to the determining.

20. The non-transitory machine-readable storage medium ofclaim 15, wherein the updating the first instance of the file space comprises:

determining a first folder exists in the first instance of the file space that has an identical name to a second folder in a second instance of the file space on a second client device, the second folder in the second instance of the file space being shared with the user of the first client device; and

automatically renaming an instance of the second folder prior to it being stored in the first instance of the file space.

Images