JP6570761B2 - Synchronization engine with storage constraints - Google Patents

Description

Cross-reference to related applications

    [0001] This application is filed on US Provisional Patent Application No. 62 / 327,379, filed April 29, 2016, US Patent Application Nos. 15 / 396,254, filed December 30, 2016, and 2017. All of those of U.S. Patent Application 15,420,014 filed on January 30, are hereby incorporated by reference in their entirety.

  [0002] Embodiments of the present disclosure generally relate to improving the performance of computer systems that provide synchronization of content items, and in particular, client devices where the allocation of synchronized content item storage is limited. And improving the synchronization of content items between content management systems.

  [0003] Content management systems allow users to share content items from one client to another. The client is a computing device that provides content items to a content management system for storage and synchronization with other clients. Other clients may be operated by other users and may be devices registered or managed by the same user. The user specifies which content item or which directory containing the content item is available to be shared with other users, i.e. synchronized with such user's client device. Typically, a content management system synchronizes predetermined content with all client devices that are designed to share the content item. As a result, each of those client devices will store a very large amount of shared content items. In some cases, the amount of storage occupied by the shared content item on the client device is substantially the amount of storage available on the client device for other items such as asynchronous content items and applications. Capacity will be reduced.

, [0004] FIGS. 1A and 1B are conceptual diagrams illustrating one embodiment of constrained synchronization. [0005] FIG. 2 is a diagram illustrating a system environment for a content management system that synchronizes content items between client devices. [0006] FIG. 3 is a diagram illustrating the software architecture of a client device. [0007] FIG. 4 is an interaction diagram of constrained synchronization for accessing existing content items in a local content directory. [0008] FIG. 5 is a constrained synchronization interaction diagram for creating a new content item stored in a local content directory. [0009] FIG. 6 is a diagram illustrating a host system environment based on constrained synchronization. [0010] FIG. 7 is a diagram illustrating an interaction diagram of constrained synchronization managed by a host device. [0011] FIG. 8 is a diagram illustrating a user interface for a local content directory having icons representing remote and local content items. [0012] FIG. 9 is a conceptual diagram illustrating constrained synchronization using predicted importance of content items. [0013] FIG. 10 is a diagram illustrating a system environment of a content management system that uses predicted content item importance for constrained synchronization. [0014] FIG. 11 is a diagram illustrating a software configuration of a client device that uses content management triggered in an idle state. [0015] FIG. 12 is a diagram illustrating a system environment for a content management system that uses content management triggered in an idle state. [0016] FIG. 13 is a flowchart illustrating a process used in content management triggered in an idle state. [0017] FIG. 14 is a block diagram illustrating the structure of a file journal according to one embodiment. [0018] FIG. 15 is a flowchart illustrating detailed processing for committing a content item, according to one embodiment. [0019] FIG. 16 is a flowchart illustrating detailed processing for replacing a content item and a placeholder item, according to one embodiment. [0020] FIG. 17 is a flowchart illustrating detailed processing for replacing a content item and a placeholder item, according to one embodiment. [0021] FIG. 18 is a flowchart illustrating detailed processing for converting a placeholder item to a content item, according to one embodiment. [0022] FIG. 19 is a flowchart illustrating an example of an algorithm for an update function that is executed by the content synchronization module upon receipt of an update entry in the update file journal. [0023] FIG. 20 is a flowchart illustrating an algorithm for reconstructing items in a shared file path, according to one embodiment. [0024] FIG. 21 is a flowchart illustrating an algorithm for reconstructing items in a shared block list, according to one embodiment. [0025] FIG. 22 is a flowchart illustrating an algorithm for configuring an update item as a new item, according to one embodiment. [0026] FIG. 23 is a flowchart illustrating an algorithm for reconstructing items with a shared journal ID, according to one embodiment. [0027] These figures depict various embodiments of the present invention for purposes of illustration only. Those skilled in the art will readily appreciate from the following description that other alternative embodiments of the arrangements and methods shown below may be used without departing from the principles of the invention described below.

<Overview of restricted synchronization functions>
[0028] A general functional overview and processing of a constrained synchronization system is described below. As a preliminary condition, a user stores a content item on a client device, and the content item is synchronized with an instance of the content item on another client device or with a host system, generally a content management system. The client device stores content items in the local content directory. Content items stored in the local content directory are synchronized with the content management system, keep a copy of the content item, and synchronize the content item with other client devices. Each client device executes a client application and allows a user to access the content management system. The client application further allows the user to set the maximum storage allocation or the size of the local content directory.

  [0029] In one form, the client device selectively determines synchronized content items that are locally available on the client device and that are stored in their entirety only on the content management system. Configured. In one embodiment, the client device receives a request to access the content item, for example from an application that needs to access the content item. The client device determines whether the requested content item is a placeholder item or a content item stored locally on the client device. A placeholder item is an item that represents or executes a content item, but does not include application data of the content item. Typically, placeholder items without storing actual application content such as image data, video data, audio data, database tables, spreadsheet data, graphic data, source or object code, or other types of content data Replicates content item metadata attributes such as the content item name and various attributes such as content item type, path information, access rights, modification information, and size. Because placeholder items only store content item metadata, they store a small amount of storage, typically only about 4 kilobytes, compared to content items that can be hundreds of megabytes or gigabytes in size. I need. Thus, using a placeholder item that represents a content item operates to save a large amount of storage space, thereby improving the functionality of the client device.

  [0030] If the client device determines that the requested content item is a placeholder item, this means that the requested content item is not currently stored on the client device but is stored in the content management system. Indicates. Accordingly, the client device downloads the content item corresponding to the requested placeholder item from the content management system. The client device further determines whether storing the content item in the local content directory exceeds a maximum storage size defined for the directory. In this case, the client device determines whether the content item or item in the local content directory can be deleted from the local content directory or replaced with a placeholder item representing the content item. In general, the client device is responsible for selecting a content item on the client device to select a content item from a local content directory that has been determined to be abandoned by the user of the client device or a user accessing the content item via a content management system. Access times (e.g., user actions of client devices or applications executing thereon), latest access times on other client devices to which the content item is shared (e.g., user actions of those client devices), Use one or more attributes of the shared content item, including the size of the content item and the access frequency. A combination of these factors may also be used to determine an abandoned content item. The client device deletes these content items so that the downloaded content items will generate a sufficient amount of storage space in the local content directory to store in it without exceeding the maximum storage size. Select the number of content items from the directory. In one embodiment, the client device allows the content item so that the total amount of storage used by those content items in the shared content directory is at least equal to or exceeds the amount of storage required to store the downloaded content item. Select the number of.

  [0031] The client device deletes the selected content item and creates a corresponding placeholder item for each of the deleted content items. The client device stores the placeholder item in the directory location corresponding to the deleted content item. The storage of placeholder items in the corresponding location allows subsequent retrieval of content items that have been deleted in a manner that is visible to the requested application.

  [0032] This embodiment can maintain access to all content items shared in the content management system while each client device has more space for other content items and applications, Provide a constrained shared storage system that improves the storage efficiency of each client device and the overall storage efficiency of the content management system. More specifically, this embodiment allows the client device to operate effectively as if it had a larger storage capacity than it actually is. For example, as if a client device with a storage allocation of only 10 GB for a local content directory has a storage allocation exceeding 4,000 GB (4 TB), a 400-fold increase in effective storage for that directory. Can work. Traditionally, such a solution for limited local storage capacity was not possible due to network connectivity and bandwidth limitations, but as a result of recent developments in the Internet infrastructure, such problems have been resolved, It allows extensive connectivity and fast upload and download speeds.

  [0033] Despite recent developments in the Internet infrastructure, the computation, upload and download times required to delete content items, replace them with placeholder items, and restore them based on user requirements are Still, it can affect device performance. Accordingly, alternative embodiments are also described that reduce the storage load on the client device in a conventional shared content synchronization method while reducing the impact on device performance as seen by the user. In one embodiment, calculations, uploads, and downloads are completed based on expected user access to shared content items represented as placeholder items. In order to predict user access to content items, the client application or content management system maintains a saved score for each content item. Here, the preservation score is a measure of importance predicted for the user of each content item. Each client device is configured to have a retention score threshold, and any content item with a very high predicted importance (represented by a retention score that exceeds the retention score threshold) is assigned to the corresponding client device. Downloaded. The saved score is calculated based on various attributes including the latest access time, location, type, size, access frequency, sharing status, number of accounts having access, number of devices having access, or number of devices storing content items. Can be done.

  [0034] Alternatively, other embodiments may be based on shared content items on the client device that exceed the client device's storage allocation while monitoring client device activity (either by a content management system or by a client application). Allow occupied storage space. When it is determined that the client device is idle, the client application deletes the content item as described above to reduce the effective storage space occupied by the content item stored on the client device. , Replace them with placeholder items. In those embodiments, the storage allocation is not always maintained, ie the occupied storage can be reduced according to the attributes of other content items. Instead of maintaining the storage allocation, for example, whenever the client device is idle, all content items with the most recent access older than a certain period (eg, 2 weeks) are deleted and placed in placeholder items It may be replaced. Although the process does not maintain occupied storage space under storage allocation, it will be desired by the user because the client device is idle, i.e., operates while it is not actively used by the user. Use a constrained synchronization system by providing an improved user experience over the above-described embodiments while providing a similar increase in effective storage capacity while reducing in a way. The client device configured as described above can be improved.

  [0035] FIGS. 1A and 1B are schematic diagrams illustrating a constrained synchronization embodiment. FIG. 1A illustrates a process for storing content items in a synchronized folder with storage constraints. FIG. 1B is a diagram illustrating the process of opening placeholder items on a client device with storage constraints.

  [0036] In FIGS. 1A and 1B, the client device 100A is one of a plurality of user control devices that can be connected to and synchronized with the content management system 110. The content management system 110 is an instantiated server that synchronizes content from multiple client devices using a network. The shared content storage directory 120 is a directory located on the client device 100 that contains content that is synchronized with the content management system 110. Storage allocation 130 is a parameter value that specifies the amount of storage space allowed for all content items in shared content storage directory 120. The storage allocation 130 may be set by a user of the client device 100A, an operating system of the client device 100, a client application of the content management system 110, a system administrator, or a policy that establishes the content management system 110. An exemplary value for storage allocation 130 is 10 GB, which means that users can store up to 10 GB content items in their content (all content item attributes and data) in shared content storage directory 120. To do. Content items 140 are stored in the shared content storage directory 120 and, after synchronization between the client device 100 and the content management system 110, the version of each content item 140 in the shared content storage directory 120 is also maintained by the content management system 110. Is done.

  [0037] As used herein, the term "content item" refers to any file, group of files, or collection of files. Any content item consisting of only a single file can alternatively be referred to as a file. Furthermore, terms such as “file table” may be used to refer to the amount of individual files or content items.

  In FIG. 1, the shared content storage directory 120 is illustrated as a box containing content items 140. The storage allocation 130 is represented by a specific length of a box representing the content storage directory 120.

  [0039] A first illustration of client device 100A and content management system 110 represents the typical state of two entities. The client device has content items 140A, 140B, and 140C in its shared content storage directory 120 (only a smaller number of content items 140 are shown for illustrative purposes, but in practice the number of content items 140 is , Thousands, tens of thousands, or more). A content management system 110 is represented to be synchronized with the client device 100A, where it retains the same version of each of the content items stored on the client device 100A despite having no storage allocation 130. To do. Furthermore, the content management system 110 supports other client devices 100B that share content items 140A. The presence of content item 140D associated with the identifier of client device 100B indicates that client device 100B is also synchronizing content item 140D with content management system 110. Accordingly, each client device 100 can synchronize the content item 140 with only the content management system 110 or with the content management system 110 and other client devices 100.

  [0040] Step 1.1 illustrates the operation of a request from client device A to save content item 140E in shared content storage directory 120. However, as shown, the addition of content item 140E to shared content storage directory 120 exceeds the remaining space available in shared content storage directory 120, where the size of content item 140E is limited by storage allocation 130. The total storage space occupied by the item 140 will exceed the storage allocation 130.

  [0041] Step 1.2 illustrates the operation of selecting a content item 140C that is left untouched to be deleted from the client device 100 so as to ensure sufficient storage available to store the content item 140E. According to one embodiment, either the client device 100 or the content management system 110 determines which content item 140 to select as left. Various methods described below can be used to determine which content items are selected to be left alone. While only a single content item 140C is selected in this example, in practice any number of content items 140 may be selected according to the storage capacity that needs to be made available.

  [0042] Step 1.3 illustrates the operation of deleting the selected content item 140C from the client device 100A. On behalf of each deleted content item, the client device 100A creates a placeholder item 160C representing the deleted content item 140C and places the placeholder item in the same location in the shared content storage directory 120 as the deleted content item 140C. Store the item. Alternatively, the content management system 110 may create the placeholder item 160 and then download the placeholder file 160C to the content storage directory 120. The placeholder item includes attributes representing the deleted content item 140C such as content name, path information, content attribute, and content size, but does not include actual data of the content item 140C. By not including the actual data of their corresponding content items, placeholder items require very little storage. For example, placeholder items typically require a minimum file size allocation provided by an operating system such as 4 KB. This small size is virtually shown in FIG. 1 using vertical lines and indicates that the size of the placeholder item is very small compared to the content item 140C itself. For example, the deleted content item 140C is several megabytes or several gigabytes (common to audio files and video files), while the storage required for the placeholder item representing such a content item is only about 4 KB. is there. As a result, the client device 100 can reduce the amount of local storage used for shared content items to a capacity that is below the storage allocation 130, thereby creating a new content item (or new content item). Sufficient space can be reserved to store the content item 140E (updated to a different version). Information identifying the selected (and deleted) content items is held in the client device 100A, allowing those items to be selectively retrieved later. This information is stored in the list 150 of content items stored remotely in the remote content item table 366 of the content management system 110 (not shown in FIG. 1A but will be described in detail later). Stored in

  [0043] Stage 1.4 illustrates the act of saving the content item 140E on the client device 100A as soon as sufficient space is made available in the shared content storage directory 120. As soon as the client device 100A successfully saves the content item 140E in the shared content storage directory 120, synchronization with the content management system 110 is initiated and the content item 140E is uploaded to the content management system 110. The content management system 110 always maintains a full copy of all content items (including placeholder items) on the client device 100A.

  [0044] Referring to FIG. 1B, the client device 100A and the content management system 110 are shown after the content item 140E has been synchronized from the client device 100A to the content management system 110.

  [0045] Stage 1.5 illustrates the operation of the client device 100A requesting access to the content item 140C (eg, using a word processor to open the content item 140C or viewing the content item in a file browser). . Here, the client device 100 determines that the requested content item is represented by a placeholder item. If the content item is stored locally, it is provided to the requesting application on the client device 100A. In this case, the requested content item is deleted from the client device 100A and is only stored remotely on the content management system 110, where the client device 100 downloads the requested content item to the content management system 110. Request to do. If there is sufficient space in the shared content storage directory 120, the content management system 110 downloads the requested content item to the client device 100A, and the client then replaces the placeholder item 160C representing the content item 140C with the content item 140C itself. Replace any requesting application with transparent access to the content item. However, in this case, the addition of the content item 140C to the shared content storage directory 120 exceeds the storage allocation 130 such that the content item 140C is shown extending outside the boundary of the shared content storage directory 120. Become.

  [0046] Step 1.6 illustrates an operation of selecting an abandoned content item for deletion from the client device 100A. In this case, the selected content item to be left is the content item 140A.

  [0047] Step 1.7 shows the operation of deleting the content item 140A and replacing it with its placeholder item 160A. This deletion creates sufficient space in the shared content storage directory 120 for the content item 140C downloaded from the content management system 110 and added to the representation of that placeholder item without exceeding the storage allocation 130. To do. Since the content item 140A to be deleted is included in the list 150 of content items stored remotely and restored to the shared content storage directory 120, the content item 140C is deleted from the list 150.

  [0048] Stage 1.8 indicates that the content item 140C can be opened by the requesting application as soon as it resides on the client device 100A. As soon as the process shown in FIGS. 1A and 1B is completed on the client device, normal synchronization occurs between the client device 100A and the content management system 110 to the content item 140 on the client device 100A. All changes are mirrored on the content management system 110. All content items 140 (even if represented by placeholder items) are retained on the content management system 110 until they are deleted from the shared content storage directory 120.

<Outline of system architecture>
[0049] FIG. 2 is a diagram illustrating the system architecture of a constrained synchronization system. Details of each component are described below, but some elements are introduced here to provide a description of constrained synchronization. Furthermore, as will be apparent to those skilled in the art, the operations and methods used for constrained synchronization necessarily require a computer and, in any embodiment, are not performed by mental steps by human actions. In addition, while the operations take advantage of the computer's ease of storing and retrieving information, transmitting and receiving information, or processing information, those skilled in the art will be able to perform such operations using the algorithms described herein. It is implemented in a specific way with respect to specially defined data, and is therefore simply common because the operating system and standard applications need to configure the computer in a different way than supplying such a computer natively. Understand that this is not a computer operation. In addition, the required configuration enhances the storage capacity of the computer over the typical normal use computer configured with conventional operating system and file management system through the steps described below.

  [0050] The client device 100 may be any suitable communication means that provides internetworking between the client devices 100 located remotely from the content management system 110, such as through a network (not shown) such as a LAN, WAN, or WAN. Communicate with the content management system 110. In general, a client device 100A having an installed client application 200A provides a content item to the content management system 110. The client application 200A includes programs and protocols required by the client device 100A to perform functions associated with storage constrained synchronization. Accordingly, the client device 100A frequently performs actions requested by the client application 200A. However, since the client device 100A and the client application 200A operate together, for ease of explanation, some of those operations are referred to using “client device 100A” as an operation element. The user of the client device 100A specifies a predetermined content item to be shared with the client device 100B, which can be, for example, another computer managed by the same user or a computer operated by a different user. The content management system 110 notifies the client device 100B and synchronizes the specified content item received from the client device 100A as local content stored in the client device 100B.

  [0051] The content management system 110 associates each content item with a namespace corresponding to the collection of content items. The namespace specifies a directory (or “folder”) in a directory structure in which a predetermined content item is stored. Associations of content items with a particular namespace are stored in a namespace table 222. The content management system 110 associates each client with the namespace that has access, along with identifying specific rights to access, modify, and delete content items in each namespace. When the client 100 is synchronized to the namespace, the client stores a local copy of the content item associated with the namespace and organizes the content item according to the location of the content if available. A user is associated with an individual client device 100 or multiple clients 100, for example, the user can synchronize a home computer, work computer, portable computer, smartphone, and tablet computer all together. To share a content item, the user specifies a namespace that should be shared with other users and / or clients. Content management system 110 then synchronizes the content items in the shared namespace across clients associated with the shared namespace. Content items stored in content management system 110 may include any type of content item including documents, data, movies, applications, codes, images, music, and the like. A content item may also be a folder or other mechanism that groups content items, along with collections, playlists, albums, file archives, and the like.

  [0052] Each user is associated with an account on the content management system 110 that includes information identifying the amount of storage to be used to store content items on the content management system 110. The client device also has a specified capacity of local storage that is the size of the shared content storage directory 120 for storing the synchronized content items, and the specified capacity is the storage allocation parameter 130 described above. It is. For example, a user account may specify that a user has 50 GB of storage available on the content management system 110 but has a storage allocation on the client device 100 of only 10 GB. In such a situation, if the user changes a locally stored shared content item, the content item increases in size, which may exceed the storage allocation on the client device 100. Similarly, the user can exceed the storage allocation on the client device 100 by creating and storing a new content item to be shared and synchronized with the content management system 110 in the shared content storage directory 120. Also good. In these cases, the client device 100 is storage limited and can no longer hold a local copy of all content items synchronized by the content management system 110, and the amount of content items shared is the storage for the client device 100. Over quota.

  [0053] While either the client device 100 or the content management system 110 is configured to select one or more content items for deletion from the local storage, they still remain remotely on the content management system 110. They can be retrieved and later retrieved and restored to the client device 100. In general, the selected content item is last accessed either on the particular client device 100 that requested the access to the content item or on all client devices 100 to which the content item is shared. The longest time has elapsed and other methods of selection will be described later. In the client-based embodiment, the client application 200 maintains information identifying the latest access to each shared content item stored on the client device 100. When the storage is restricted, the client application 200 selects one or more content items (hereinafter abbreviated as “LRA”) that have been accessed last and the longest time has elapsed. In a host-based embodiment, the content management system 110 maintains access data for all content items, and the system 110 is accessed when any content item is accessed on any client device 100 to which the content item is shared. Update this information at any time. The LRA selection is just one of many possible idle content item selection methods (referred to herein as “UCSM”), each of which can be implemented as a host-based or client-based system. . Any UCSM may examine the vnode reference for each content item to determine if it is suitable for deletion. The vnode for each content item includes information regarding the number of accesses to the content item and the status indicator of other content items including whether the content item is currently in use or open.

  [0054] For ease of explanation, whenever a content item is selected to be removed from resident on the client device 100 in response to storage limitations, this action is most UCSM accessed by the user. Since it operates to identify the content item with the lowest possibility, it is referred to herein as “selecting an abandoned content item”. An abandoned content item refers to a content item selected by any UCSM outlined in the following description.

  [0055] Basic LRA selection: To perform basic LRA selection, the client application 200 is a queue of content items ordered by the last locally accessed date and accesses the head of the queue. It holds a queue where content items that have been the longest passed have come. The date and time when each content item was last accessed is held in the content access history table. Accessing a content item includes operations for creating, opening, previewing, or changing the content item. Any number of those actions are considered access, for example, in this embodiment, opening, modifying, or saving a content item is considered access while a preview of a content item is considered access. It does not have to be. The cumulative total of storage sizes (eg, the total to date) starts from the content item identified in the queue that has been last accessed and has the longest time elapsed (ie, the first content item in the queue). Is calculated for each content item listed in the queue up to the content item located at the end of. If storage is limited, the client application 200 determines the amount of storage space needed to store the content item, and thus identifies the index of the content item whose cumulative storage size exceeds the storage space requirement Advance the queue. The identified index is used to select all the content items including the index of the queue to be deleted from the shared content storage directory 120 on the client device 100 described above.

  [0056] These processes are further described in Table 1. In this example, 75 MB of storage is required to store content items. Since the total of content items A and B is only 70 MB, the deletion of those two content items cannot provide a sufficient amount of storage for the items. Accordingly, content items A, B, and C with a total cumulative size of 150 MB are selected with corresponding indexes 00, 01, and 02 (as indicated by the rightmost column designation).

  [0057] Remote LRA selection: LRA selection also provides access to the content item through the content management system 110, either directly on it or on the client device 100 sharing the version of the content item. It can be based on remote access by other users who have. To accomplish this, in one embodiment, each client device 100 synchronizes its content access history table with the content management system 110, eg, during a normal content item synchronization operation or at other times. This embodiment allows each client device 100 to maintain current access information for all content items shared with any other client device. Alternatively, in a host-based embodiment, content management system 110 may maintain a content access history table that includes access history for each content item across all client devices designated to be synchronized and shared. , Thereby having a current updated list for use in LRA selection. Thus, remote LRA selection includes the content management system 110 selecting the content item that has been accessed last and has the longest time that exceeds the storage space that requires a cumulative storage size. In this embodiment, the queue is ordered by the most recent access time from all client devices that are synchronized with respect to the content item.

  [0058] Table 2 is an example of how a remote LRA can be implemented. In this example, content items B and C were last accessed remotely on different client devices at 2014/5/24 and 2014/4/5 respectively, but both (as described in Table 1) Both are accessed locally at the end of 2014/3/24. Changing the date of the most recent access for items B and C due to their remote access will move them further in the queue compared to the case where basic LRA selection is used. As a result, in this example, items A and D are selected instead of A, B and C.

  [0059] Size selection of content items: Another factor that can be used to select content items to delete is their size. In one embodiment, the size is used to minimize the number of content items that are deleted and stored remotely from the client device 100. This can be achieved by ordering queues by size (minimum to maximum) instead of date accessed. The required storage space value can then be compared to individual sizes until content items having a size that exceeds the required storage space are identified. Client application 200 will then select the content item to delete. If no single content item is larger than the required storage space, the largest content item is selected, its size is subtracted from the required storage space value, and the process is repeated from the beginning of the queue.

  [0060] Table 3 is an example of the selection method. In this example, 40 MB of storage is required to store content items. Since item B is the first content item with a queue index that exceeds the required storage value of 40 MB, it is selected to be deleted from client 100.

[0061] Selection based on content item size and access time: The size selection method described above may select content items that are frequently accessed for deletion. By taking into account both size and access time, the content management system can avoid deleting content items from the client device 100 that may be requested by the user in the near future. In one embodiment, the bivariate selection method calculates a weight score for each content item based on the amount of storage for each content item that contributes to reaching the required storage allocation and its most recent access date and time. Achieved by: For example,
Score = w ₁ S + w ₂ A
Here, S is a metric representing the size of the content item, A is a metric representing the time since the content item was last accessed, and w ₁ and w ₂ are weights. The weights for A and S can be based on their relative importance, as determined by the user, or based on historical content items that indicate access patterns for content items on a particular client device 100. be able to. The queue is then ordered by score and the first content item in the queue is selected for deletion.

[0062] An example of the method of this embodiment is shown in Table 4 below. For ease of illustration, the access time metric A includes the difference between the current time and the most recent access time for a particular content item, and the current time and the time of the last accessed item (here, last used It is the ratio of the difference of 2014/9/3). In this example, the size metric has the following relationship:
For s> = r: S = r / s
For s <r: S = s ² / r ²
Here, s is an item size of content, r is a necessary storage space, and S is a size metric. This piecewise function has a maximum of 1 when s = r.

  [0063] In the example displayed in Table 4, the required storage space is 40 MB and the weights w1 and w2 are both 1. A size metric and an access time metric are calculated and then used to calculate a total score for each content item. In this example, item B has the highest score and is selected for deletion from the client device 100. If the selected content item is smaller than the required storage space, the newly required storage space is calculated as the difference between the old storage space and the size of the first selected content item, and the score is recalculated. A new queue is generated for all content items using the newly calculated necessary storage space, and the selection process is repeated.

  [0064] In order to better select the access frequency and the latest selected abandoned content item, other factors such as frequency may be considered in addition to the access time. A high frequency, low recency content item is a content item that was frequently selected in the past (6 months or more ago), but has not been selected recently, and a low frequency, low recency content item is frequently accessed A content item that has never been The frequency of access may be measured in relation to the average frequency, type, namespace, source domain, or other content item attribute on a particular client device or any collection of client devices. For example, if a content item has not been accessed on the client device in the last 4 months but has been accessed 25 times before that time, the user has more access than a content item that has been accessed only once in the past and is a similar resiliency. May be related.

[0065] In one embodiment, in addition to the most recent access to each content item, the number of accesses to each content item is maintained (either at the client device 100 or the content management system 110). A score is determined for each content item as a weighted combination of metrics representing each variable. For example, the weighting score for each content item is based on the access frequency of the content item and its latest access date. For example,
Score = w ₁ F + w ₂ A
Here, F is a metric representing the access frequency, and A is a metric representing the time since the last access to the content item. w ₁ and _{w 2} is a weight. The weights of A and F may be based on their relative importance, as determined by the user, by the system administrator, or based on historical content item access patterns for content items on a particular client device 100. it can. The queue is then ordered by score. The cumulative sum is calculated at each index and compared to the required storage space. When the required storage space exceeds the cumulative sum, the index in the queue and all content items at the index are selected for deletion from the client device 100.

[0066] Table 5 is an example of this selection method. In this example, the required storage space is 40 MB and the weights w ₁ and w ₂ are both 1. The queues are ordered by the total score and compared to the storage space that requires a cumulative sum. This results in items C and E selected for deletion from client device 100.

  [0067] Any of the above USCMs may consider the entire folder in a single queue index instead of a single individual file. For example, if LRA UCSM is used and the folder contains multiple files, the most recently accessed file in that folder has an earlier access date and time than all other content items in the shared content directory It would be more effective to select an entire folder that was left unattended (especially if you need a lot of storage space). Alternatively, the combined metric for a folder may be an average, median, or other statistic that allows content items in the folder to be generalized and placed in a queue.

  [0068] As described below, any of the foregoing methods may be used to select an abandoned content item for deletion from the client device 100. The process of selecting an abandoned content item allows for enhanced storage capacity on the client device as provided by the constrained content management system 100.

<Outline of content management system>
[0069] A synchronization method using content management system 110 between client devices 100A and 100B may be described with reference to the architecture illustrated by FIG. One of the many possible synchronization methods that can be used for storage constrained synchronization is described below.

  [0070] The content management system 110 stores the content items in the data store 218. Content items are stored in fixed-size parts called blocks. Depending on the block size implementation, in one embodiment, the block is 4 megabytes in size. Thus, small size content items are stored in a single block, while large size content items are divided into dozens, hundreds, or more blocks for content management system 110 storage. Can be stored. The metadata includes a plurality of blocks of content items and a block list that defines the order of the blocks in the content items.

  [0071] The pending block table 220 maintains a list of pending blocks that are expected to be received by the content management system. The pending block table 220 stores an association between a plurality of blocks (identified by a block identifier) and a namespace to which the transmitted block indicated by the client 100 belongs.

  [0072] Namespace table 222 stores data associating individual content items with namespaces and maintains data associating each namespace with a client.

  [0073] The metadata server 212 is responsible for managing requests from clients to add new content items to the content management system ("commit"). The metadata server 212 also receives a request to synchronize content items from the client device 100. The metadata server 212 holds a record of the latest time when the client device 100 is synchronized with the content management system 110. When a synchronization request is received from a client device 100, the metadata server 212 determines any content item committed to the namespace synchronized to that client device 100 after the latest synchronization time stamp. Further, the metadata server 212 determines any pending blocks received after the latest synchronization time stamp.

  [0074] The notification server 216 communicates with the client 100 and in particular notifies the client that new data is available. The notification server 216 maintains a list of clients 110 associated with each namespace in the namespace table 222. When the notification server 216 receives an alert from the block server 214 or the metadata server 212 that a new block is available for a given namespace, the notification server 216 is associated with the namespace from the namespace table 212. Identify the client. The notification server 216 notifies the client 100 associated with the namespace to activate the client 100, indicating that a new block is available for the identified namespace.

  [0075] Normal synchronization between two clients 100, client 100A and client 100B occurs as follows. First, the client device 100A adds an additional content item to the shared data. The additional content item is then transmitted to the content management system 110. The content management system 110 notifies the client device 100B that the additional content item is in the shared data, and the client device 100B retrieves the additional content item from the content management system 110 as the client device 100B. The content management system 110 maintains a list of content items and pending blocks that are expected to be received by the content management system 110 using the pending block table 220 and is received by the content management system 110 on the client device 100B. As a block to be notified, a block corresponding to the content item is downloaded. Pending blocks are those blocks that correspond to content items that are expected to be received by the content management system 110 for receiving at the client device 100B before the content item is committed to the content management system 110. Used to identify blocks that can be provided.

  [0076] In order to manage the content items being transferred, the content management system 110 maintains a list of pending blocks along with a namespace associated with the pending blocks. When a pending block is received, the client associated with the namespace is notified and a transfer for the received block can be initiated. Accordingly, the uploading client (providing a new content item) and the downloading client (receiving a new content item) transfer blocks asynchronously to the content management system 110.

<Overview of client device>
[0077] Each client device 100 maintains a local copy of shared data that is synchronized with a desktop, laptop, tablet, mobile device, or other client using the content management system 110 and installed client application 200. A computing device such as a system. Shared data may be synchronized only with clients associated with a single user, or may be synchronized with clients associated with multiple users. Client device 100 handles shared data and includes modules and applications for adding the data, as further described with respect to FIG.

  [0078] FIG. 3 shows the modules of the client application 200. The client application 200 includes various modules and a data store for synchronizing data with the content management system 110. The client application 200 includes a content synchronization module 310, a hashing module 320, a download module 330, an upload module 340, and a storage management module 350. In addition, the client application 200 maintains a data store that includes a file journal 360, a resident file table 362, shared data 364, a remote file table 366, a configuration file 368, and a block cache 370. In addition to the client application 200, FIG. 3 also shows a storage kernel extension 384 that resides on the operating system of the client device. The client application 200 and its associated kernel extension that uses the module instance client application 200 as a particular computer can perform the functions described herein and describe the storage capacity and functional performance of the client device. Make improvements possible.

  [0079] Shared data 364 is data that is synchronized in content management system 110 and includes content items received from content management system 110. As users add, modify, or delete content items in shared data 364, those changes are synchronized with content management system 110. The hashing module 320 and the block cache 370 operate to identify blocks that contain content items that are uploaded to the content management system 110. The hashing module assigns block identifiers by executing any suitable hashing algorithm such as MD5 or SHA-1. The content synchronization module 310 then uses those identifiers to compare the resident blocks located in the block cache 370 with the blocks maintained by the content management system 110. Although those modules are present in the present embodiment, the implementation of this block is not necessarily essential to the present invention for storage constrained synchronization.

  [0080] Within the client application 200, when the data of the shared data 364 on the client device 100 is modified or added to the shared data 364, the modification to the shared data 364 is sent to the content management system 110. Is done. Client device 100 is also configured to receive notifications from content management system 110. When the client device 100 receives the notification, the client device 100 inquires the content management system 110 about the modification to the shared data 364. When the shared data is modified, the client device 100 requests a modification from the content management system 110 to store the shared data on the client device 100. In some cases, the modified data may be associated with a content item represented by a placeholder item. In this case, the client device 100 may suspend requests for correction data from the content management system 110 until access to the content item represented by the placeholder item is requested by an application on the client device 100. Alternatively, when a shared content item is modified by another client device 100, the content management system 110 may request that the constrained client device 100 restore the content item represented by the placeholder item, As a result, the modifications can be synchronized at the expense of other content items that reside on the constrained client.

  [0081] Within the client application 200, the file journal 360 stores a table listing the metadata of all content items accessible to the account using the client application 200. The metadata includes a revision date, a namespace, and a block list corresponding to each content item. Content items that are not resident or not synchronized are still included in the file journal 360.

  [0082] The resident file table 362 stores a list of files resident in the client device 100 regardless of storage limitations.

  [0083] The remote file table 366 stores a list of files selected to be deleted from the client device and replaced with placeholder items. These files are only held by the content management system 110 so that other users can access the files.

  [0084] Configuration file 368 is a file maintained by client application 200 and includes storage allocation 120 at the client device. In some embodiments, the storage allocation 120 may be created by a user or by a computer system that has control via the client application 200. For example, the operating system may change the storage allocation 120 to maintain sufficient storage capacity for use by other applications.

  [0085] The storage kernel extension 384 is configured to monitor a request from the application to the operating system 380 to access the content item and determine whether the requested content item is a placeholder item. This is a means for executing the function. The storage kernel extension 384 establishes direct modifications to the operating system structure and functionality to allow for increased effective storage capacity on the client device.

  [0086] The kernel extension 384 monitors requests to open content items managed by the client application 200. The kernel extension 384 determines when a request to open a content item managed by the client application 200 is made by monitoring the file system 382 on the operating system 380. When a request for a content item is made in the file system 382, the kernel extension 384 determines the content item pathname to determine if it is in a content item stored in the shared content storage directory 120. Investigate.

  [0087] The kernel extension 384 determines whether the requested content item is a placeholder item by determining whether its size is below a threshold size, or the identification of a placeholder item is Can be achieved based on extended file attributes for content items managed by the client application 200. A file attribute indicating a placeholder item may be assigned to the placeholder item so that the kernel extension can identify the placeholder item without examining the size of the requested content item. When the kernel extension unit 384 determines that the file is a placeholder item, the kernel extension unit notifies the client application 200 of identification information.

  [0088] FIG. 4 illustrates one embodiment of a process for accessing a content item that is not resident on the client device 100, but is included in the file system as if the content item was resident on the client device 100. It is an interaction diagram. File system 382 receives a request to open a content item in a synchronized folder on client device 100 (400). The request may be from any application such as a file explorer, a word processor, a document reader, or an image editor. The storage kernel extension 384 intercepts such a file system request and obtains the path name of the requested content item (402). The storage kernel extension 384 uses the pathname to determine whether the content item is a placeholder item (404). The storage kernel extension 384 checks the size of the requested content item to determine whether it falls below a predetermined threshold or otherwise matches the size of the shadow item (4 KB). You may determine whether it is a placeholder item. Alternatively, the storage kernel extension 384 can read file attribute extension information that stores a value indicating whether the content item is a placeholder item or a normal content item. If the content item is not a placeholder item, as a result, the storage kernel extension 384 allows the request to continue as usual and provides a file handle to the file system, which opens the content item.

  [0089] Upon determining that the content item is a placeholder item, the storage kernel extension 384 sends a request identifier number (information about the request including the request type) and a file path to the storage management module 350. (406) The file name is passed. The storage management system 350 deletes the file name from the remote file table 366 (408). The storage management system 350 then activates a download thread that identifies content items that require synchronization from the content item (412). As soon as the requested content item is deleted from the remote file table 408, the download thread can request content information from the content management system 110, including the size of the requested content item in preparation for download. (414). The storage management module 350 receives size information from the content management system 110 (416) and determines whether storing the content item on the client device 100 exceeds a predetermined storage limit (418). If the storage limit is exceeded by adding the requested content item, the storage management module 350 selects one or more content items stored on the client device 100 for deletion (422). However, if the storage limit is not exceeded, the storage management module 350 proceeds to the process of downloading the content item (430).

  [0090] If the storage allocation 130 is exceeded by adding the requested content item to the shared content storage directory 120, the storage management module 350 uses the requested content item before requesting download (430). One or more content items to be moved can be selected to ensure sufficient storage space possible, thereby preventing the shared content storage directory 120 from being occupied more than its allocated space. The storage management module 350 selects a content item to be deleted by first determining (420) an abandoned content item using any of the UCSMs described above (422). When the access history of a particular content item or other information related to each selection method is stored in the host system, a request is made to the host system to update the client application 300 version of that information (FIG. 4). Not shown). As soon as the current version of the access history or any other necessary information is obtained for each content item in the content management system 110, the storage management module 350 can determine an abandoned content item (420). ).

  [0091] The storage management module then selects an abandoned content item to be deleted from the client device (422). In this embodiment, to select a content item to delete (422), the storage management module 350 is generated by the USCM in use to create a storage space that is at least equal to the size of the requested content item to be downloaded. Examine in detail the queues to be played. The selection of the abandoned content item for deletion can be performed using any method described above.

  [0092] The storage management module 350 then adds the name of the selected content item to the remote file table 366. Upon completion of the addition (424) (426), the storage management module 350 deletes the selected content item from the shared content storage directory 120 (428), and then deletes the deleted content item for each deleted content item. Create a corresponding placeholder item that has the same metadata and location as the item, but does not include content information about the content item. Placeholder items may be represented in the client user interface as if they were still resident on the client device 100. FIG. 8 is a diagram illustrating how a placeholder item is represented in the user interface of the client device 100.

  [0093] When the selected content item is deleted, there is sufficient storage space on the client device 100 so that the requested content item does not exceed the storage limit of the shared content storage directory 120. Can be downloaded from Accordingly, the storage management module 350 transmits a download request 430 to the download module 330. The download module 330 then initiates a download (432) with the content management system 110. When the content item is downloaded to the download module 330 (434), it is passed to the storage management module 350 (436), the requested content item is saved in the previously specified location (438), and downloaded to the storage kernel extension 384. Is completed (440). In one embodiment, the storage management module 350 appends the content of the downloaded content item to the placeholder item's metadata and updates the content item's attributes to indicate that the content item is no longer a placeholder item. This allows the requesting application to transparently access the requested content item using the same file handle and identification information used to initially request access to the content item. The storage kernel extension 384 then passes the file handle (442) to the file system 382 and allows the requesting application to open (444) the content item.

  [0094] FIG. 5 is an interaction diagram illustrating one embodiment of a process for storing content items in the shared content storage directory 120 to approach the storage allocation 130. The content item is a newly created content item in the shared content storage directory 120, a content item relocated to the shared content storage directory 120, or already in the shared content storage directory 120, and its size increases. It may be a content item modified by the method. The process begins when the application makes a request to the operating system file system 382 to save the content item in the sync folder (500). The storage kernel extension 384 monitors this request and receives the request ID, file path, and size from the file system (502). Thereafter, the storage kernel extension unit 384 transmits the information to the storage management module 350 (504). The storage management module determines whether the addition of a new content item exceeds the synchronized folder storage limit (506). If the storage limit is not exceeded, the file system 382 allows the content item to be stored normally. If the storage limit is exceeded, the storage management module 350 determines the neglected content item (508) and selects it as a content item to be deleted from the client device. When abandoned content items are selected, their names are added to the remote file table 366 (512), which prevents the content from being synchronized by the content management system 110. The storage management module then deletes the selected content item from the client device 100 and replaces it with a placeholder item that has the same metadata and location as the deleted content item but does not include the content (514). When the process is complete, there will be sufficient storage space in the restricted folder in the storage management module (516) so that the original content item can be saved. Storage management module Thereafter, an upload thread is activated (518) and the metadata is accessed (520), whereby the content of the stored content item is uploaded to the content management system 110 (522).

  [0095] In addition to automatically deleting content items and creating placeholder items, some embodiments also allow specific content stored only remotely in content management system 110 to the user. Allows selecting an item. This may be implemented simply by allowing the user to select from a context menu (eg, “right click”) on a particular synchronized content item. The client application 200 then presents the user with an option to make the selected content item remote. When the user selects the option, the content item is deleted from the client device 100, the name of the content item is added to the remote file table 366, and the placeholder item having the same metadata and location as the original content item is the original content. Created to represent an item. If the user subsequently desires access to the content item, the same process as shown in FIG. 5 may be used to retrieve the content item from the content management system 110.

  [0096] In some embodiments, when UCSM actually selects a content item to delete from the client device 100, when the storage allocation 130 is reached, the user remains resident on the client device. The client device is configured to allow a content item to be selected. This embodiment provides operational improvements that allow the user to maintain rapid access to certain important content items. In this embodiment, client application 200 allows a user to access a context menu and then select an option to force content items to remain resident on client device 100. When selected, the name of the content item is added to the resident file table 362. The resident file table 362 is accessed later in the UCSM used by the storage management module 350, as shown at 422, and all content items in the table are excluded from the selection process. For example, when a given content item is selected for deletion, the resident file table 362 is examined to determine if the selected content item is listed there, and if so, the selected Content items are ignored and other content items are actually selected by UCSM.

  [0097] Content related to placeholder items on the client device 100 is not synchronized, thus complicating content management. For example, if a user on a client device moves a content item represented as a placeholder item on a second client device, then if the second client device does not receive synchronization data about the placeholder item, the The location will change on the first client device, but will not change on other client devices. For example, a content item may be completely deleted from the content management system 110 by one client device 100 while being represented by a placeholder item on a different client device 100. When this situation occurs, the user of the second client device 100 can attempt to access the content item represented by the placeholder item just to find that it no longer exists. In order to avoid such a confusing situation, in some embodiments, the content management system 110 is configured to synchronize placeholder items only for metadata, i.e., any attributes of the placeholder items are When changed, content management system 110 modifies all client devices 100 that have access to the content item, regardless of whether the content item is represented as a placeholder item on any of those client devices. Synchronized attributes Therefore, when a content item is deleted from one client device, a placeholder item representing the content item is also deleted on any other client device 100. Alternatively, in some embodiments, the content item content item is on another client device so that it is resized to fit within the remaining storage in the shared content storage directory 120 on the client device 100. In the case where the content item is modified, it may be downloaded to the client device 100 even when access to the content item is not required.

  [0098] Some of the foregoing embodiments ensure that the client application 200 does not exceed the predetermined storage allocation 130 and that operates to request data from the content management system 110. Represents a synchronization system with A host-based embodiment is shown in FIG. 6, where the content management system 110 manages a constrained synchronization process that includes maintaining information identifying remote and resident content item information at each client device 100. . The host-based embodiment provides similar benefits of increasing the effective storage capacity on the client device 100 while reducing the computation required from the client device, thereby comparing to other embodiments. To improve the performance of the client device 100. The constrained content management system 600 includes the elements of the content management system 110 shown in FIG. 2 and further utilizes the storage management module 350 along with the necessary data files necessary for the storage management module 350 to function properly. To be corrected. Within the constrained content management system, the metadata server 212, block server 214, notification server 216, data store 218, pending block table 220 and namespace table 222 are implemented in a manner similar to that implemented in the content management system 110. Function. In addition, the storage management module 350 functions in a manner similar to when residing on a client device, and operates to determine when storage space limits are exceeded and to properly create placeholder items. The storage management module 350 is also operative to receive information from the client device 100 about requests made by the operating system 380. When a request is made to open one or more content items, information about the request is sent by the storage management module 350 to the remotely monitored content management system 110, thereby placing a placeholder item on the client device 100. Downloads necessary to provide access are made. The storage management module 350 uses the client configuration file 610 to provide information regarding the storage configuration on each client device associated with the constrained content management system. The synchronization table 620 is a record of all content items on the client device client device that require synchronization with the constrained content management system 600, and some of the content items are placeholder items and metadata synchronization. The content items contained in this table are a subset of the content items located in the data store 218. Further, in this embodiment, the synchronization table 620 includes both a resident file table 362 and a remote file table 366 that are configured to indicate the client device 100 where each content item is to be held remotely or resident. May be replaced by using For embodiments using the latter configuration, the implementation of metadata synchronization for placeholder items is easier if the placeholder items are specified directly in the remote file table 366 of each client device 100. . User data 630 is stored on the constrained content management system 600, which allows the storage management module 350 to determine an abandoned content item.

  [0099] FIG. 7 is an interaction diagram illustrating one embodiment of a process of storage synchronization with host management constraints. The application on the client device 100 requests the content item to be stored in a folder that is synchronized on the client device (700). The storage kernel extension unit records the request ID, file path, and content item size (702), and transfers the information to the client application 200 (704). The client application 200 transfers the size information of the content item to the storage management module 350 on the constrained content management system 600 (706). The storage management module 350 requests a storage limit for the particular client that received the content item size from the client configuration file 610 (708). The storage management module 350 determines whether the storage limit is exceeded by comparing the size added to other content items resident on the client device 100 with the storage allocation received from the client configuration file 610 (712). ). The storage management module 350 requests content data on the client from the synchronization table 620 (714), so that content items to be deleted from the client can be selected from the synchronized content items on the client. The synchronization table responds 716 with synchronized content data for a particular client. The storage management module 350 requests user access data from user data 630 stored on the host device used to determine the LRA content item (718). The data is immediately received from the user data table 630 (820). The storage management module 350 determines LRA content items (722) and selects them to be deleted from the client (724) to provide the necessary storage space. The storage management module 350 deletes the content item and creates a placeholder item (728), and sends a request to the client application 200. Permission is granted to the client application 200 to complete the original request 700 to save the content item (730). Finally, the storage management module updates the user data to reflect the access to the first content item to the saved content item (732) and can then be used to upload a new content item. Therefore, the metadata server 212 requests synchronization of the client device 100 (734).

[00100] FIG. 8 illustrates an example of a user interface of a client device 100 that operates in conjunction with a content management system that provides constrained synchronization. The synchronized file folder 800 operates like the shared content storage directory 120. Folders 800 have icons 810A ( .m4a music file ), 810B (.xlsx spreadsheet ), 810C ( .docx word processing file ), 810D ( .mat Matlab file ), and 810E (jpg image file), respectively. Contains a number of content items that are represented. Each icon 810 is superimposed with a status icon 820 indicating the storage status of the content item.

  [00101] The status icon 820A ("check icon") indicates that the content item is currently resident on the client device 100 and is synchronized with the current version of the content item held by the content management system 110. .

  [00102] Status icon 820B indicates that the content item is resident on client device 100 when synchronization with the content management system is complete.

  [00103] The status icon 820C indicates that the content item is a placeholder item and is not currently resident on the client device, but is still retained on the content management system 110.

  [00104] Status icon 820D indicates that the content item is resident on the client device and is synchronized with that version maintained by content management system 110. Further, a green circle with a pin icon 840 indicates that the content item has been selected to remain resident on the storage-restricted client device 800.

  [0100] FIG. 9 illustrates an alternative embodiment of constrained synchronization that predicts user access to a particular content item remotely at a client device and downloads the predicted content item prior to the access. It is a conceptual diagram. This approach provides a further improvement in the operation of the client device by removing the user's waiting time in most cases when retrieving content items from the content management system 110 over the network. A saved score 900 is calculated for each content item 140 within the shared content storage directory 120. The score is a measure of the expected importance of the content item, as described below, and is calculated as a function of the most recent access time or many other factors that the user's request was determined to be expected Can be done. Further, each content storage directory 120 is configured with a storage score threshold specified by a user or set with a predetermined value. The predicted importance of the content item exceeds the retention score threshold 910 of a particular shared content storage directory 120 on the client device 100 that has access to the content item, as measured by the same content item retention score 900. Each time, a content item is downloaded to the shared content storage directory if it is remote to the client device, and held in the shared content directory if it is resident on the client device.

  [0101] Stage 9.1 illustrates an exemplary state of a content management system that predicts user access to a content item. In this example, the content management system 110 manages two client devices 100A and 100B. Shared content storage directories 120A and 120B are located in each client device. Shared content storage directory 120A stores content items 140A, 140B, and 140C, while shared content storage directory 120B stores content item 140D and shadow item representation 160A of content item 140A. Synchronized versions of all content items 140 are stored in the content management system 110.

  [0102] Further, each content item 140 has a corresponding saved score 900, 900A is the saved score of content item 140A, and 900B is the saved score of content item 140B. Each shared content storage directory is also configured with a saved score threshold 910, where 910A is a saved score threshold for shared content storage directory 120A, and 910B is a saved score threshold for shared content storage directory 120B.

  [0103] At stage 9.1, content item 140A is not retained in shared content storage directory 120B. In this case, there is no content item that exists in the shared content storage directory 120 that has a saved score 900 that is lower than the saved score threshold 910, but this scenario is characterized by other embodiments described above or below. May be used in addition to. For example, if the storage allocation is sufficiently large, it may not be necessary to maintain the file remotely even if the storage score 900 is lower than the storage score threshold 910 if the storage allocation is still affecting.

  [0104] At stage 9.2, the user of the client device 100A performs a user action 920 for the content item 140A that is considered to be an access to the content item 140A. In this example, since the saved score 900 is calculated as a function of the latest access time, the saved score 900A of the content item 140A is increased from 20 to 60 (the magnitude of this change is arbitrary for the purposes of this example). Details of the calculation of the stored score will be described later, but there is a possibility that the same score will not be changed.)

  [0105] At stage 9.3, the content management system 110, or in some embodiments the client application of the client 100B, has a saved score 900A for the content item 140A and a shared content storage directory 120B where the content item 140A is remote. It is determined whether or not the storage score threshold 910B is greater than or equal to 910B. Since the saved score 900A exceeds the saved score threshold 910B, the content item 140A is downloaded to the client device 100B and stored in the shared content storage directory 120B.

  [0106] As with the UCSM described above, there are many stored score calculation methods. Typically, the stored score can be normalized to the user's behavior attributes, and as a result, the stored score for the same content item is different on each client device or globalized so that the score is the same on each client device . The advantage of the normalized saved score is that it averages the difference in user behavior. For example, if the stored score is a function of the most recent access time of a content item such that the saved score increases as the time difference between the current time and the most recent access time decreases, when compared to a content item shared with a less active user, A more active user will push up the saved score of the content item shared with the user. For a third user that is shared with both active and inactive users, if the saved score is not normalized, the recent access by the active user by the third user rather than the recent access by the inactive user In spite of the low prediction, only the items from the active user will have the highest stored score, so the stored score will lose their predicted quality. When the stored score is normalized, it can be normalized to the attributes of a specific user or a specific content item.

  [0107] The following method is an illustration of a method for determining a stored score or a score that predicts user access to a content item. Further, the stored score may use a combination of a plurality of methods described below to create the most predictive measure of predicted importance. Typically, the preservation score increases as the predicted importance of the content item increases, however, the opposite is also true if convenient for this embodiment. In this case, the corresponding saved score threshold becomes the minimum value, and the content item is saved in the corresponding shared content storage directory when the saved score of the content item is equal to or smaller than the saved score threshold. For the purposes of this disclosure, an increasing preservation score is assumed below as a default case.

[0108] Latest access scoring: In the latest access scoring, the stored score of a content item is a function of the latest access time of the content item. The stored score may simply be the reciprocal of the difference in seconds between the current time and the latest access time:
RS = 1 / (t _C -t _A )
Here, RS is the saved score, t _C is the current time, and t _A is the latest access time.

  [0109] If normalization is required in a particular embodiment, the user's or client device's, defined as the number of accesses to any shared content item by a particular user or a particular client device within a predetermined time period Various user attributes such as access frequency may be used. Alternatively, the average latest access time of a plurality of content items shared by a specific user or client device may be used.

  [0110] Access frequency scoring: In access frequency scoring, the retention score of a content item increases as the number of accesses to the same content item increases within a predetermined time period. To normalize access frequency scoring, the access frequency for a given content item is divided by the average access frequency for all content items on the client device or shared with the user, or vice versa. It may be enlarged.

  [0111] Location-related access scoring In location-related access scoring, the saved score of a first content item is the latest access time, access frequency, or any other characteristic of the content item itself, A weighted combination with similar characteristics of additional content items stored in the same folder as the first content item. This means that access to a content item in a folder is a prediction of access to other content items in the same folder.

  [0112] Similar access scoring In similar access scoring, the saved score of the first content item is the latest access time, access frequency of the content item itself, and additional content having attributes similar to the first content item A weighted combination with similar characteristics of the item. The attributes are the content item type, size, location, user having access to the content item, and the like. This means that access to a similar content item is a prediction of other access to the content item.

  [0113] Criteria-based preservation scoring: In reference-based preservation scoring, the preservation score of a content item is based on the number of previously identified prediction criteria satisfied by the content item. For example, access of content items by other users within 24 hours, access frequency greater than 5 last week, and access to sufficiently similar content items within the last 3 days are all in the next 6 hours. It may be a predetermined criterion that is predicted to attempt to access the remote content item. Thus, the content item retention score may be increased by a predetermined magnitude for each of the criteria satisfied by the content item. The increasing magnitude for satisfying a particular criterion may be proportional to the predicted strength of the particular criterion.

  [0114] FIG. 10 is a diagram illustrating a system environment of a content management system that uses predicted importance of content items for constrained synchronization. Most of the constrained content management system modules shown in FIG. 10 perform their similar or identical functions described with reference to FIG. 6, except as noted above. Therefore, the functions of all the modules in the content management system 1000 will not be described in detail here.

  [0115] The content management system 1000 includes a metadata server 212, a block server 214, a notification server 216, a data store 218, a pending block table 220, a namespace table 222, a storage management module 350, a client configuration file 610, a synchronization table 620, User data 630, a saved score table 1010, and a saved score module 1020 are included. Client configuration file 610 and user data 630 have significant changes from the previous version shown in FIG. Client configuration file 610 is modified to include a retention score threshold for each shared content storage directory for each client device, while user data is modified to include user data related to the retention scoring method used. Is done. The saved score module 1020 captures user data 630 and data from the data store 218 to generate a saved score table 1010. The saved score table is a table that lists saved scores of each content item managed by the content management system 1000. A separate stored score table may be closed for each client device if normalization is used to calculate the stored score. When the content item's saved score is updated, the saved score module 1020 determines whether the content item corresponding to the recently changed saved score is remote on any client device and the storage of those client devices. To determine whether any of the score thresholds is exceeded, the client configuration file 610 and the synchronization table 620 are examined. If the saved score threshold is exceeded, the saved score module causes the storage management module 350 to perform the necessary download and replace the displayed shadow item.

  [0116] FIG. 11 shows the software architecture of the client application 1100 for constrained synchronization according to another embodiment. In the present embodiment, while the client device is determined to be idle by the client application, the remote content item is downloaded, the abandoned content item is deleted, and the shadow file is created. This change in the timing of the constrained synchronization process provides a similar increase in effective storage capacity while improving client devices by providing functional improvements over the previously described embodiments. To perform these functions, the idle state that triggers this embodiment changes the system architecture shown in FIG. In this embodiment, the client application 1100 includes a synchronization module 310, a storage state module 1110, a file journal 360, a resident file table 362, shared data 364, a remote file table 366, a configuration file 368, and a block cache 370. The The content synchronization module 310 further includes a hashing module 320, a download module 330, an upload module 340, and a storage management module 350. The saved state module 1110 further includes a calculation module 1120, a state comparison module 1130, an action module 1140, and a system state module 1150. Unless otherwise specified, all of the modules and data tables described above have the same functionality as described above, with slight modifications as will be recognized by those skilled in the art to adapt the new module. Optional key changes are described below.

  [0117] The system state module 1150 uses the storage kernel extension 382 to measure the system activity of the operating system 380. System activity includes, but is not limited to, processor frequency or other CPU utilization metric as a percentage of non-idle processor cycles (with or without multi-processor core adjustments), client device 100 threads or processes Can be measured using process activity. Network activity metrics may also be used, including network utilization defined as bits per second or packets per second as a percentage of the maximum rate for a particular port or connection. In addition, a memory usage metric that includes the amount of available or free random access memory (RAM) may be used to measure system activity. The system state module 1150 may use the activity metrics described above or any other suitable activity metric individually or in combination to measure overall system activity.

  [0118] If the system activity measurement falls below a predetermined activity threshold, the system state module 1150 reports to the saved score module 1110 that the client device is currently idle. This activity threshold may be defined as a percentage of the total computational resources of the client device, as defined by the activity metric, or the activity threshold may be defined as a specific value of the activity metric. For example, the activity threshold may be defined as the state of the client device 100 that uses less than 25% of the available processing resources. Alternatively, the activity threshold may be defined as a state where other processes of the client device 100 use less than 2 GB in total, or so that there is at least 4 GB of available total memory on the client device. .

  [0119] When the client device 100 is determined to be idle by the system state module 1150, the state calculation module 1120 determines the storage state of the shared content storage directory 120. Typically, the saved state comprises content items that reside on the client device and a set of attributes corresponding to those content items. Those attributes may include content item size, last access time, access frequency, directory location, or any other suitable attribute that indicates the importance of the content item for storage on the client device. Further, the storage state may be represented by a set of statistics calculated using at least one of the attributes described above.

  [0120] The comparison module 1130 receives the saved state from the state calculation module 1120, and then the current saved state of the shared content storage directory 120 may be specified by the user as defined in the configuration file 368. Compare with the threshold storage state. The threshold storage state may be a set of criteria associated with an attribute, or may be a calculated statistic of a client device included in the storage state. The comparison module 1130 determines whether the current storage state satisfies a threshold storage state criterion. If these criteria are violated (eg, not satisfied), the comparison module 1130 may send content items corresponding to attributes that violate the threshold storage criteria, or statistics calculated based on those attributes, to the action module 1140. Report.

  [0121] The action module 1140 receives a report from the comparison module 1130. Thereafter, an action for returning the retention state to the threshold storage state criterion is determined. These actions may include deleting content items from the shared content storage directory 120 and replacing them with shadow items or replacing shadow items representing remote content items with the content item itself. Once those actions are determined, action module 1140 requests content synchronization module 310 to complete the necessary actions.

  [0122] Alternatively, the content management system itself may perform constrained synchronization triggered by an idle state that reduces the computational load on the client device and increases the availability of the device to other users. Good. FIG. 12 shows the system environment for completing this task. The constrained content management system 1200 includes a metadata server 212, a block server 214, a notification server 216, a data store 218, a pending block table 220, a namespace table 222, a storage management module 350, a client configuration file 610, a synchronization table 620, It includes user data 630, a storage state table 1210, and a storage state module 1220. Unless otherwise specified, all of the modules and data tables described above have the same functionality as described above, with slight modifications as will be recognized by those skilled in the art to adapt the new module. Optional key changes are described below.

  [0123] In this version of the embodiment, the client application 200 on the client device connected to the content management system 1200 reports the status of the client device to the content management system 1200. If the client device is idle, the content management system 1200 uses the save state module 1220 to determine the save state of the shared content storage directory 120 on the idle client device. The save state module then updates the save state table 1210, which includes the current save state of all client devices connected to the content management system 1200. The saved state module 1220 then performs the same steps as the saved state module 1110 using potentially similar submodules as described in the description of FIG.

  [0124] The storage state of the shared content storage directory may be determined using various methods. Typically, the saved state is criteria-based and is maintained if the client application periodically determines that the client device is idle. However, it is also possible to numerically implement the storage state and the threshold storage state so that each state is represented by a statistic calculated using the attributes of the content item resident on the client device. If the save state is criteria based, the threshold save state is a set of criteria that the content items in the shared content storage directory should satisfy. In addition, in the case of criteria-based save states, the user may be given the option of selecting save state criteria, which allows customization of content item categories that reside on the client device.

  [0125] The period used to check each client device may be a predetermined value of the content management system set by the user, or determined based on the usage pattern of a particular client device Also good. For example, if users access content items on their client devices every 24 hours on average, the time period may be set to ensure that the shared content storage directory is maintained until 24 hours have passed. Good.

  [0126] Instead of periodically checking the shared content directory, maintain the shared content directory only if the shared content directory meets a second set of criteria indicating urgency, eg, near hardware storage limits It may be.

  [0127] Storage Space Criteria: One possible set of criteria is to have storage allocation criteria. For example, the storage allocation can be set to 20 GB, but instead of operating similarly to the above embodiment, the content management system allows content items stored in the shared content storage directory to be stored until the device is idle. It is allowed to exceed the reference value (20 GB in this example). Thereafter, a similar process for determining an abandoned content item is used to delete the appropriate content item and satisfy the storage space criteria of the shared content storage directory.

  [0128] Access time reference The second reference may be an access time reference. For example, the criterion may be a state in which a content item having the latest access time prior to a predetermined time interval cannot reside in the shared content storage directory. Those content items would be allowed to reside in the shared content storage directory until the client device becomes idle. At this point, the save state module will simply request the deletion of all content items with the most recent access time prior to the predetermined time interval.

  [0129] Another set of content item size criteria is a content item size criteria. In this method, a threshold is set for the size of each content item. Thus, if the device is idle, any content item that exceeds or falls below the threshold is excluded from residency on the client device.

  [0130] Access frequency criterion: Finally, the access frequency criterion is used to set the minimum number of accesses within a predetermined time interval required to remain resident on the client device. If a particular content item is not accessed frequently enough, it is deleted from the client device when idle.

  [0131] Note that the list of preservation criteria is not exhaustive. Further, these criteria may be used in combination with others to provide more complex rules.

  [0132] FIG. 13 is a flowchart showing a function of content management with restrictions triggered by an idle state. First, the system performs a check to determine if a particular client device is idle (1300). This step is performed either periodically or in response to the content storage directory reaching a predetermined threshold. If the device is idle, the system determines the save state of the client device (1310). Thereafter, the system compares the current saved state of the shared content storage directory with the saved state criteria for the shared content storage directory. If the criteria are satisfied by the current saved state of the shared content storage directory, the system again checks (1300) to determine if the client device is idle. If the saved state criteria are violated, the system identifies (1330) an action to be performed on the shared content storage directory that is required for the shared content storage directory to meet the saved state criteria. The system then performs (1340) those actions on the shared content storage directory to match the predetermined retention state criteria.

<Synchronization of placeholder items in parallel with content items>
[0133] FIG. 14 is a block diagram illustrating the structure of a file journal 360 according to one embodiment. File journal 360 includes an entry for each content item or placeholder in the shared content storage directory of the client device. The file journal includes two sections, a local file journal 1400 and an update file journal 1410. Each journal includes metadata about a list of file items (listed items may include the same or different items). The local file journal 1400 includes metadata for items currently resident on the client device. The metadata may include a local namespace ID, a local journal ID, a local file path, a local block list, a local extended attribute, a local size, a local change time, and a local synchronization type. Each version of an item is uniquely identified by a namespace ID and journal ID pair. Each field of the local file journal is described below.

  [0134] Local namespace ID: A metadata value indicating the namespace associated with the item.

  [0135] Local journal ID: A metadata value indicating a specific journal entry corresponding to the version of the item.

  [0136] Local file path: A metadata value indicating the location of the item in the shared content storage directory.

  [0137] Local block list: A metadata value indicating a block including the item.

  [0138] Local extended attribute: A metadata value including an additional attribute of the item. These may include the latest access time, creation time, or any other attribute of the item.

  [0139] Local size: A metadata value indicating the size of the item. When the item is classified as a placeholder item, the local size of the item is the size of the content represented by the placeholder item.

  [0140] Local modification time: A metadata value indicating the time when the latest modification to the item occurred.

  [0141] Local synchronization type: A metadata value indicating whether the item is a content item or a placeholder item.

  [0142] The update file journal 1410 is added with update metadata for items resident on the client device, received from the content management system 110 or created by the function of the client application 200. If there is no update for a particular item, there will be no update file journal entry for that item 1400. The update metadata may include an update namespace ID, an update journal ID, an update file path, an update block list, an update extended attribute, an update size, an update change time, an update synchronization type, and a force reconstruct value. Good.

  [0143] Except for the forced reconfiguration value, the field of the update file journal entry corresponds to the local file journal entry. A difference between an entry in the local file journal entry and an updated file journal entry indicates that the content item associated with the entry has been changed in some way. For example, if the update file path is different from the local file path, it indicates that the item associated with the entry (by the journal ID of the entry) has moved from the local file path to the update file path.

<Commit (add) content item from client device to content management system>
[0144] FIG. 15 is a flowchart illustrating one embodiment of an algorithm for committing a content item. The content synchronization module 310 detects 1500 new content items or changed content items in the shared content storage directory 120. The changed content item indicates that one of the attributes of the content item is changed, including at least one of a file path (or file name), a block list, an extended attribute, a size, and a latest change time. In contrast to creating a new content item, when the content synchronization module 310 detects a change to an existing content item, at 1510 the local journal ID is a value representing the pending state of the content item for conflict resolution purposes. (For example, zero).

  [0145] As soon as a new content item or a modified content item is detected, the hash module 320, at 1520, uses the hash value of any new or modified data as a new block to recreate the block list. Calculate and determine any new or modified attributes of the content item. The block list and attributes of the new or changed content item are then committed to the content management system 110 at 1530. The client device then creates, in 1540, local metadata for creating a new entry in the local file journal 1400 that includes the new journal ID on the namespace for the new or changed version of the detected content item. The set is received from the content management system 110. At 1550, the client device 100 creates a new local file journal entry based on the received metadata. Based on the association of the namespace table 222, the content management system 110 communicates the update entry to the update file journal 1410 of the other client device 100 associated with the new content item or changed content item namespace. An algorithm for managing entries in the update file journal 1410 will be described below with reference to FIG.

<Commit (add) placeholder item from client device to content management system>
[0146] FIG. 16 is a flow chart illustrating one embodiment of an algorithm for committing placeholder items. The content synchronization module 310 detects, at 1600, a new placeholder item or a changed placeholder item in the shared content storage directory. The placeholder item may be a JSON dictionary or another representation having at least two fields including a namespace ID and a journal ID. The namespace and journal ID stored in the placeholder item correspond to the local namespace ID and local journal ID of the local file journal 1400. When a placeholder item is changed or created, the corresponding local journal ID is set at 1610 to a value (eg, 0) that represents the pending state in the placeholder item for the purpose of conflict resolution.

  [0147] The new or changed attribute of the placeholder is determined by the content synchronization module 310 at 1620. Changes that can occur to a placeholder item include a change in the name of the placeholder item and a change in the file path of the placeholder item. Actions that can result in the creation of a new placeholder item may include copying the placeholder item or moving the content item from one namespace to another.

  [0148] When a new or modified attribute is determined by the content synchronization module 310, the journal ID and namespace ID of the placeholder item is 1630 to commit the placeholder item attribute to the content management system 110. used. The client device then creates local metadata for creating a new entry in the local file journal 1400 that includes the new journal ID on the namespace for the new or modified version of the detected placeholder item 1640. Are received from the content management system 110. At 1650, the client device 100 creates a new local file journal entry based on the received metadata. The placeholder item itself is also updated to reflect the new journal ID. The update entry corresponding to the commit event is then communicated to other client devices 100 associated with the new or changed placeholder item namespace based on the association in the namespace table 222. An algorithm for managing entries in the update file journal 1410 will be described below with reference to FIG.

<Replace content item with placeholder item on client device>
[0149] Content items that reside on the client device 100 may be marked by placeholder items. This can occur due to a direct user action or determination of the client application 200 or the content management system 110 according to one of the methods described above for determining unintended content items. FIG. 17 is a flowchart illustrating one embodiment of an algorithm for replacing a content item with a placeholder item. Once the content item is identified by replacement with a proxy placeholder item, the content synchronization module 310, at 1700, removes the update synchronization type field from the local file journal 1400 to the update file journal 1410 for the content item. Copy the entry. In 1710, the content synchronization module 310 sets the update synchronization type field of the entry to indicate the placeholder item. Subsequently, the content synchronization module indicates that the forced reconfiguration field of the update file journal entry requires the content item to be reconfigured despite the fact that the updated version of the content item has the same attributes as the original content item. “True” shown in 310 is set.

<Replace placeholder item with content item on client device>
[0150] The process for replacing a placeholder item with a content item is basically the reverse of the process for replacing a content item with a proxy placeholder item. Placeholder items representing content items on the client device 100 may be marked to be restored to the content items. This can occur from a direct user action or by determination of the client application 200 or content management system 110 according to one of the methods described above for determining unintended content items. FIG. 18 is a flowchart illustrating one embodiment of an algorithm for replacing placeholder items with content items. When a placeholder item is identified for restoration to a content item, the content synchronization module 310, at 1800, removes the update synchronization type field from the local file journal 1400 to the update file journal 1410 for the placeholder item. Copy the entry. The content synchronization module 310 sets the update synchronization type field of the entry at 1810 to indicate the content item. Subsequently, in the forced reconfiguration field of the update file journal entry, the content that the placeholder item needs to be reconfigured despite the fact that the update entry for the placeholder item has the same attributes as the local journal entry. “True” shown in the synchronization module 310 is set.

<Update function>
[00105] FIG. 19 is a flowchart illustrating an example of an algorithm of the update function 1900 executed by the content synchronization module 310 upon receiving an update entry of the update file journal 1410. The update function 1900 is to determine what changes need to be made to resolve an update file journal entry received from the content management system 110 or generated by the content synchronization module 310 itself. , A series of steps executed by the content synchronization module 310. An update journal is not limited, but if a new journal ID is created on the namespace based on a commit from a different client device associated with the namespace, the content item residing on the client device is (directly) Placeholder items that represent content items on the client device (directly, either by a typical user action or by a decision by the client application 200 or the content management system 110) To be replaced by the content item it represents (either by a user action or by a decision of the client application or content management system). It may be created in a number of situations including when it is click.

  [0151] The content management system 110 creates a new journal ID when a new content item or content item version is added to the namespace. When this occurs, the content management system 110 pushes the metadata associated with the new content item or content item version from the metadata server 212 to the client device 100 associated with the namespace. When the transmitted metadata is received by the client device 100, the content synchronization module 310 stores the metadata as an entry of the update file journal 1410. As a result, the update synchronization type of the entry may not be included in the transmitted metadata, but instead may be determined by the client application 200 according to one embodiment.

  [0152] When the metadata is stored as an entry in the update file journal 1410, the update function 1900 displays an entry in the update file journal 1410 (which represents an item change or a new version) and an entry included in the local file journal 1400. To resolve the differences between the following steps: The update function first determines at 1910 whether the update file path of the update file journal entry is equal to the local file path of any local journal entry stored on the client device 100. If there are local journal entries having the same file path, the update function then displays the update journal entry in 1920 by determining whether the update journal ID of the update entry matches the local journal ID of the local entry at 1920. It is determined whether the item to be processed is a new version of the item placed on the client device 100. If the update journal ID does not match the local journal ID, the content synchronization module 310 determines that a new version of the item represented by the local journal entry exists and reconfigures the item in the shared file path. Start processing. This process will be described later in detail with reference to FIG.

  On the other hand, if the content synchronization module 310 determines at 1920 that the update journal ID is equal to the local journal ID, the content synchronization module 310 determines at 1940 whether the forced reconfiguration value is true for the update entry. To do. If the forced reconfiguration value is true, the content synchronization module 310 starts processing for reconfiguring the item with the shared journal ID. This process will be described later in detail with reference to FIG.

  [0154] If the content synchronization module 310 determines that the forced reconfiguration value is false at 1940, then the update journal entry is considered as a duplicate update at 1990, and further action by the client application 200. Deleted without.

  Returning to step 1910, update function 1900 also determines at 1910 that none of the local file paths of the entries stored in the local file journal 1400 are the same. In this case, the content synchronization module 310 determines at 1930 whether the update block list of the update entry matches any of the local block lists of the local file journal 1400. If the update block list is unique, as a result, the update function 1900 indicates that the update entry indicates a new item, and configures the update item as a new item according to the processing described in detail later with reference to FIG. judge.

  [0156] If the content synchronization module 310 determines that the update block list matches the local block list of the local file journal 1400 at 1930, then the content synchronization module has a block list with the update journal ID matching at 1950. It is determined whether or not it matches the local journal ID of the local entry. If the journal IDs do not match, then the content synchronization module 310 reconstructs the item using the shared block list. This process will be described later in detail with reference to FIG.

  On the other hand, if the content synchronization system determines that the update journal ID matches the local journal ID from the local journal entry with the matching block list in 1950, the update function 1900 then returns to step 1940 and Proceed as you did.

<Reconfiguration of items in the shared file path>
FIG. 20 is a flowchart illustrating one embodiment of an algorithm for reconstructing items in a shared file path. The algorithm described by FIG. 20 occurs as a result of a negative determination in step 1920 of the update function 1900. Reorganization of items in a shared file path will convert the content item to a placeholder item if a new version of the content item is uploaded to the content management system 110 or if the content item remains in the same file path Occurs when it is done or vice versa. The first step of the algorithm is at 2000 whether the local journal ID of a local file journal entry with a shared file path is pending, indicating that the content item corresponding to the local entry is currently being edited. judge. If the corresponding local journal ID is pending, the system receives a new local journal ID from the content management system 110 until the system completes any further changes to the content item at 2005. Wait until. When a new journal ID is received, at 2010, the updated change time of the update entry is compared with the new local change time of the local entry to determine which changes have been made more recently. At 2015, the conflict is resolved based on the comparison of change times and the specific edits made to the item. During conflict resolution, if the same blocks listed in the update block list are still relevant, they will be downloaded and stored in the shared file path. If the conflict resolution process results in an item that is different from the final product of the local or updated change, then that item is again hashed and a new block list is generated through FIG. . If a local change to the item takes precedence over a remotely made change (represented in the update entry), the update entry may be discarded as a result.

  [0159] Returning to step 2000, the content synchronization module 310 determines in 2000 that the local journal ID of the local entry having the shared file path is not pending, and as a result, the item corresponding to the entry is currently being edited. Indicates that it has not been. Based on this determination, the content synchronization module 310 determines at 2020 whether the updated synchronization type is set to “placeholder item” or “content item”. If the update synchronization type indicates “content item”, then the content synchronization module 310 checks 2030 to determine whether the update block list is equal to the local block list of the local journal entry having the shared file path. . If the two block lists are equal, the content synchronization module 310 does not need to download additional blocks from the content management system 110, but instead simply deletes the local journal entry before deleting the update journal entry from the update file journal 1410. It simply replaces the attribute of the update journal entry with the attribute of the update journal entry.

  [0160] If it is determined at 2030 that the two block lists are different, the content synchronization module 310 receives the update block requesting the block of the update block list from the content management system 110 at 2045, and the content synchronization module 310 creates a content item updated in the shared file path based on the received block at 2050. Finally, the local journal entry is replaced at 2055 with the updated journal entry before the update entry is deleted from the update file journal 1410.

  [0161] Returning to step 2020, if the content synchronization module 310 determines that the item is an update synchronization type indicating that the item should be a "placeholder item" at 2020, the content synchronization module 310 results in 2025. In the shared file path, the local synchronization type of the item is determined. If the local synchronization type indicates that the item is already a placeholder item, at 2035, an updated placeholder item is created in the shared file path that replaces the original placeholder item. The updated placeholder item includes metadata about the updated namespace ID and journal ID. After creating the updated placeholder item at 2035, the local journal entry is replaced with the updated journal entry at 2055, and the updated journal entry is deleted from the updated file journal 1410.

  [0162] Returning to step 2025, if the content synchronization module 310 determines that the local synchronization type represents "content item", ie, represents a content item, the content synchronization system, at 2040, selects a content item in the shared file path, Replace with a placeholder item with an updated namespace and journal ID pair. After the content item is replaced with a placeholder item at 2040, the content synchronization module 310 replaces the local journal entry with the updated journal entry at 2055 and deletes the updated journal entry from the update file journal 1410.

<Reconfiguration of items in the shared block list>
[0163] FIG. 21 is a flowchart illustrating one embodiment of an algorithm for reconstructing items in a shared block list. The algorithm of FIG. 21 occurs as a result of a negative determination in step 1950 of the update function 1900. If the item is located in a different file path in the shared block list but has the same block list as the updated block list, the content synchronization module 310 reconstructs the item with the shared block list. This situation occurs when an item moves from one file path to another.

  [0164] First, the content synchronization module 310 determines at 2100 whether the local journal ID is pending. If the local journal ID is pending, the content synchronization module 310 proceeds to the contention resolution step described above (see 2105, 2110, 2115 in FIG. 21 and 2005, 2010, 2015 in FIG. 20). As a result of the conflict resolution, the content item corresponding to the local journal entry having the shared block list may be moved to the updated file path, may be moved to a new file path, or the item may be moved to a new file path. The content may be changed at the same time as the content is moved to.

  [0165] If it is determined that the local journal ID is 2100 and not pending, then the content synchronization module 310 determines, at 2120, the update synchronization type of the update entry. If the update synchronization type indicates that the update item should be a “content item”, then the content item with the shared block list is 2125 from the local file path to the update file path indicated in the update journal entry. Moved. The content synchronization module 310 then replaces the local journal entry with the update journal entry and deletes the update journal entry from the update file journal 1410 at 2130.

  [0166] Returning to step 2120, if the content synchronization module 310 is 2120 and it is determined that the update item is an update synchronization type designating that it is a "placeholder item", the content synchronization module 310 is 2135, Judge as local synchronization type. If the local sync type is “content item”, then the content item corresponding to the local entry and having the shared block list is replaced at 2140 with a placeholder item having an updated namespace ID and journal ID. . The placeholder item is then moved to the position indicated by the update file path. When the content item is replaced with a placeholder item, the content synchronization module 310 replaces the local journal entry with the updated journal entry and deletes the updated journal entry from the updated file journal 1410 at 2130.

  [0167] If it is determined that the local synchronization type should be "placeholder item" at 2135, then the local placeholder item with the local namespace ID and journal ID pair is 2145 at the updated namespace ID and journal ID. Is replaced with an updated placeholder item having a pair. The content synchronization module then saves the update placeholder item in the update file path. When the local placeholder item is replaced with the updated placeholder item at 2145 and the placeholder item is rearranged to the new file path, the content synchronization module 310 replaces the local journal entry with the updated journal entry at 2130 and updates the file. Delete the update journal entry from the journal 1410.

<Configure update items as new items>
[0168] FIG. 22 is a flowchart illustrating one embodiment of an algorithm for configuring an update item as a new item. The algorithm of FIG. 22 occurs as a result of a negative determination in step 1930 of the update function 1900. If the entry in the local file journal 1400 does not have a local file path or block list that matches the update file path or update block list of the update entry, the content synchronization module 310 configures the update item as a new item. .

  [0169] When configuring a new item, the content synchronization module 310 first determines at 2200 the update synchronization type for the update item. If the update synchronization type is for a placeholder item, the content synchronization module 310 at 2220 creates the update entry that creates a placeholder item having an update namespace ID and update journal ID pair in the update file path. Is then copied to the local file journal 1400 at 2215 and the update entry is deleted from the update file journal 1410.

  [0170] When the content synchronization module 310 is 2200 and it is determined that the update item is an update synchronization type indicating that the update item is a content item, the content synchronization module 310 is updated from the content management system 110 at 2205 as a result. Request a block specified by a block list. Upon receipt of the requested block, the content synchronization module 310 creates an updated content item in the update file path at 2210 using the requested block. As soon as the content item is created, the update entry is then copied 2215 to the local file journal 1400 and the update entry is deleted from the update file journal 1410.

<Reconfiguration of items with a shared journal ID>
[0171] FIG. 23 is a flowchart illustrating one embodiment of an algorithm for reconstructing items with a shared journal ID. The algorithm described by FIG. 23 occurs as a result of the affirmative determination of step 1940 of the update function 1900. When the forced reconfiguration value is identified as “true”, the item is reconfigured with the shared journal ID. This means that when an update journal entry is created by the content synchronization module 310 itself, the item in the shared content storage directory has been converted from a content item to a placeholder item, or vice versa. .

  [0172] First, the content synchronization module 310 determines at 2300 the update synchronization type indicated by the update entry. If the update synchronization type indicates a placeholder item, the content synchronization module 310 at 2320 converts the content item corresponding to the local journal entry having the shared journal ID to a placeholder item that includes a shared namespace ID and journal ID pair. replace. When the content item is replaced with a placeholder item at 2320, the local entry of the local file journal 1400 is then replaced with the update entry at 2315, and the update entry is deleted from the update file journal 1410.

  [0173] If the content synchronization module 310 determines that the update synchronization type indicates a content item at 2300, the content synchronization module 310 requests a block of the update block list from the content management system 110 at 2305. Upon receiving the requested block, the content synchronization module 310 replaces the placeholder item corresponding to the local journal with the shared journal ID at 2310 with the content item created from the requested block. When the placeholder item is replaced with the content item at 2320, the local entry of the local file journal 1400 is then replaced with the update entry at 2315, and the update entry is deleted from the update file journal 1410.

  [0174] The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration; they are not intended to be exhaustive or to limit the invention to the same forms disclosed herein. Those skilled in the art can appreciate that various modifications and variations are possible in light of the above disclosure.

  [0175] Certain portions of the description describe embodiments of the invention relating to the manipulation of algorithms and symbolic representations in information. The descriptions and representations relating to these algorithms are commonly used by those skilled in the data processing arts to effectively convey the substance to others skilled in the art. While functionally, computationally or logically described, it is understood that these operations should be implemented by a computer program, equivalent electrical circuitry, microcode, or the like. Furthermore, it has proven convenient, as a module, to refer to variations of these operations without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combination thereof.

  [0176] Any of the steps, operations, or processes described herein may be performed or implemented by one or more hardware or software modules, alone or in combination with other devices. In one embodiment, a software module may be implemented in a computer program product comprising a computer readable medium that includes computer program code that may be executed by a computer processor that performs any or all of the described steps, operations, or processes. Good.

  [0177] Embodiments of the present invention also relate to an apparatus for performing the operations herein. The apparatus can be specially configured for the required purposes and / or can include a general purpose computing device selectively activated or reconfigured by a computer program stored on the computer. Such a computer program can be stored on a non-transitory, tangible computer readable storage medium or any type of medium suitable for storing electronic instructions that can be coupled to a computer system bus. Further, any computing system referred to herein may include a single processor, or may be an architecture that employs multiple processor designs to enhance computing performance.

  [0178] Embodiments of the present invention may also relate to products generated by the computing processes described herein. Such products may include information resulting from a computational process in which information is stored on a non-transitory, tangible computer readable storage medium, and any of the computer program products or other data combinations described herein Embodiments can be included.

  [0179] Finally, the terms used in the specification were selected primarily for readability and explanatory purposes, and were selected to outline or limit the subject matter of the present invention. It is not a thing. Accordingly, it is intended that the scope of the invention be limited not by this detailed description, but rather by any claims issued by this application based on the description herein. Accordingly, the disclosure of embodiments of the invention is intended for purposes of illustration and is not intended to limit the scope of the invention as defined in the following claims.

Claims (20)

A method,
Storing a local file journal on a client device, wherein the local file journal includes a plurality of local entries, each of the plurality of local entries corresponding to a synchronization item on the client device, and the synchronization item A local journal ID of the synchronization item, a local block list of the synchronization item, and a plurality of local attributes of the synchronization item, each synchronization item being a content item on the client device or Corresponding to shadow items,
By the client device, the method comprising: receiving an update entry from the content management system, the updated entry and updating the namespace ID of the content item, and update journal ID of the content item, the update block list of the content item A plurality of update attributes of the content item and an update synchronization type of the content item;
Comparing the received update entry with the plurality of local entries in the local file journal to identify a shadow item on the client device that represents the content item stored in the content management system; The shadow item does not include content data of the represented content item, but includes at least the local namespace ID of the represented content item and the local journal ID of the represented content item;
Updating the identified shadow item by replacing the local namespace ID of the shadow item with the update namespace ID and replacing the local journal ID of the shadow item with the update journal ID;
Replacing the local entry corresponding to the shadow item with the update entry. The method of claim 1, further comprising:
Determining that the shadow item should be replaced with the represented content item based on a comparison that identifies a difference between the updated block list and the local block list of the identified shadow item. ,
Downloading a block indicated by the updated block list of the content item from the content management system;
Replacing the shadow item with the represented content item containing the downloaded block at the client device. The method of claim 1, further comprising:
Determining that the shadow item should be replaced with the represented content item based on a forced reconfiguration value associated with the update entry;
Downloading a block indicated by the updated block list of the content item from the content management system;
Replacing the shadow item with the represented content item containing the downloaded block at the client device. The method of claim 1, comprising:
The update entry includes an update file path, and each of the plurality of local entries includes a local file path;
Comparing the received update entry with the plurality of local entries further comprises comparing the update file path with the local file path for each of the plurality of local entries. And how to. The method of claim 4, further comprising:
Determining that the shadow item should be replaced with a new file path based on the comparison;
Relocating the shadow item on the client device to the location specified by the update file path. The method of claim 1, further comprising:
Based on the comparison, determining that the shadow item is pending based on a change by a user of the client device;
A method comprising: performing conflict resolution based on an update change time included in the update entry and a change time included in the shadow item. The method of claim 6, further comprising:
Committing the change by a user of the client device to the content management system in response to determining that the change time of the shadow item is later than the update change time. A computer program comprising instructions that, when executed by a client device, causes the client device to perform an operation,
Receiving an update entry from a content management system by the client device, wherein the update entry includes an update namespace ID, an update journal ID, an update block list, a plurality of update attributes, and an update synchronization type; Including,
Comparing the received update entry with a plurality of local entries, each of the plurality of local entries having a local namespace ID, a local journal ID, a local block list, and a plurality of local attributes; A local entry corresponds to a content item or shadow item on the client device;
Identifying a shadow item on the client device based on the comparison, wherein the shadow item represents a content item stored on the content management system, and the shadow item represents the represented content item Including at least the local namespace ID of the represented content item and the local journal ID of the represented content item without including the content data of
Updating the identified shadow item by replacing the local namespace ID of the shadow item with the update namespace ID and replacing the local journal ID of the shadow item with the update journal ID;
Replacing the local entry corresponding to the shadow item with the update entry. The computer program according to claim 8, further comprising:
Based on the comparison, determining that the shadow item should be replaced with the represented content item;
Downloading the block specified by the updated block list from the content management system;
Replacing the shadow item with the represented content item containing the downloaded block at the client device. A computer program according to claim 9,
The computer program product, wherein the determination that the shadow item should be replaced with the represented content item is made based on a forced reconfiguration value associated with the update entry. A computer program according to claim 8,
The update entry includes an update file path and each of the plurality of local entries including a local file path;
Comparing the received update entry with the plurality of local entries further comprises comparing the update file path with the local file path for each of the plurality of local entries. Computer program. The computer program according to claim 11, further comprising:
Determining that the shadow item should be replaced with a new file path based on the comparison;
Relocating the shadow item on the client device to a location specified by the update file path. The computer program according to claim 8, further comprising:
Based on the comparison, determining that the shadow item is pending based on a change by a user of the client device;
A computer program comprising: performing conflict resolution based on an update change time included in the update entry and a change time included in the shadow item. 14. A computer program according to claim 13, further comprising:
Committing the change by the user of the client device to the content management system in response to determining that the change time of the shadow item is later than the update change time. A system,
A processor;
A Turkish computer readable storage medium to store the instructions, when executed by the processor,
Receiving an update entry from a content management system by a client device, wherein the update entry includes an update namespace ID, an update journal ID, an update block list, a plurality of update attributes, and an update synchronization type; , That,
Comparing the received update entry with a plurality of local entries, each of the plurality of local entries having a local namespace ID, a local journal ID, a local block list, and a plurality of local attributes; A local entry corresponds to a content item or shadow item on the client device;
Identifying a shadow item on the client device based on the comparison, wherein the shadow item represents a content item stored on the content management system, and the shadow item represents the represented content item Including at least the local namespace ID of the represented content item and the local journal ID of the represented content item without including the content data of
Updating the identified shadow item by replacing the local namespace ID of the shadow item with the update namespace ID and replacing the local journal ID of the shadow item with the update journal ID;
System characterized in that it comprises said update entry and replace it with the including computer-readable storage medium the local entry corresponding to the shadow item. The system of claim 15, further comprising:
Based on the comparison, determining that the shadow item should be replaced with the represented content item;
Downloading the block specified by the updated block list from the content management system;
Replacing the shadow item with the represented content item containing the downloaded block at the client device. The system of claim 16, comprising:
The system wherein the determination that the shadow item should be replaced with the represented content item is made based on a forced reconfiguration value associated with the update entry. The system of claim 15, comprising:
The update entry includes an update file path and each of the plurality of local entries including a local file path;
Comparing the received update entry with the plurality of local entries further comprises comparing the update file path with the local file path for each of the plurality of local entries. System. The system of claim 18, further comprising:
Determining that the shadow item should be replaced with a new file path based on the comparison;
Relocating the shadow item on the client device to the location specified by the update file path. The system of claim 15, further comprising:
Based on the comparison, determining that the shadow item is pending based on a change by a user of the client device;
A system comprising: performing conflict resolution based on an update change time included in the update entry and a change time included in the shadow item.