JP7355959B2 - External location synchronization - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a cross reference to U.S. Application No. 17/133,006 entitled “SYNCHRONIZING AN EXTERNAL LOCATION” filed on December 23, 2020; 17/132,954, entitled ``EXTERNAL LOCATION,'' and both applications claim priority to U.S. Provisional Patent Application No. 63, entitled ``SYNCHRONIZING AN EXTERNAL LOCATION,'' filed on October 19, 2020. USC §119(e) to No./093,699, which application is expressly incorporated herein by reference in its entirety.

Content management systems allow users to store and manage all necessary content items in one place. Content management systems typically store content items on servers and allow users to access content items over a network. Some content management systems allow users to synchronize content items stored on local client devices to the content management system. However, content management systems do not provide synchronization of content items stored on external drives attached to client devices.

FIG. 1 depicts an example system configuration illustrating a content management system that interacts with client devices, according to some embodiments.

FIG. 2 illustrates an example client synchronization service according to some embodiments.

FIG. 3A is a flowchart of a method for synchronizing external locations, according to some embodiments.

FIG. 3B is a flowchart of a method for accessing a client device's external location through selection of an anchor object, according to some embodiments.

FIG. 4 is a flowchart of a method for generating anchor objects, according to some embodiments.

FIG. 5 is a flowchart of a method for synchronizing anchor objects, according to some embodiments.

FIG. 6A shows an example graphical user interface, according to some embodiments.

FIG. 6B shows an example graphical user interface, according to some embodiments.

FIG. 6C shows an example graphical user interface, according to some embodiments.

FIG. 6D shows an example graphical user interface, according to some embodiments.

FIG. 7 illustrates an example computer system according to some embodiments.

The present technology can synchronize objects located outside of a content management system's synchronization directory. Content management systems that provide synchronization between cloud storage and client devices synchronize content to specific directories on the client device. Objects located outside of the synchronization directory are typically not accessible to the content management system's synchronization service. However, some of a user's most important objects may be located outside of the synchronization directory, and therefore there is a need to be able to synchronize such content items.

Objects stored in external directories on external hard drives present an even greater challenge, but objects on external hard drives are some of the most important to users for backup through synchronous content management systems. sell. For example, users typically utilize external hard drives to archive important objects that are not needed on a daily basis, but are not very important. External hard drives may not always be accessible to the computer running the sync client application, may be in a different format than the client device's hard drive, and may , they present a complication in that they may be read-only.

A further problem can arise if the external hard drive stores a larger number of bytes than the available storage space on the client computer's hard drive. In such cases, the object cannot be first stored on the client's hard drive before being uploaded to the synchronous content management system.

This technology overcomes many of these issues and allows content management systems to integrate external directories, even on external hard drives, without first copying the objects to be synchronized to a location on the client device's hard drive. allows you to synchronize.

In some embodiments, the disclosed techniques are deployed in the context of a content management system that has object synchronization capabilities and collaboration features, among other things. An exemplary system configuration 100 is shown in FIG. 1, illustrating a content management system 110 that interacts with a client device 150.

account

Content management system 110 may store objects in association with accounts and perform various object management tasks, such as retrieving, modifying, browsing, and/or sharing the object(s). . Additionally, content management system 110 may allow an account to access object(s) from multiple client devices.

Content management system 110 supports multiple accounts. A subject (user, group, team, company, etc.) may create an account in content management system 110 and account details may be stored in subject database 140. The subject database 140 may identify registered subjects by subject ID and may store profile information of registered subjects in association with the subject ID. In some cases, the registered subject's profile information includes the subject name and/or email address. The subject database 140 includes account types (e.g., various tiers of free or paid accounts), storage space allocated, storage space used, and client devices with registered content management client applications 152 residing on the device. 150, may include account management information, such as security settings, personal configuration settings, etc. In some embodiments, some information associated with an account may not be directly stored; rather, this information may be derived. For example, the storage space used may be stored explicitly or calculated when needed.

In some embodiments, subject database 140 need not store complete information associated with a subject's account. Some of the information associated with a subject's account may be stored in other databases of content management system 110, such as metadata database 146, or in a database external to content management system 110. good.

Subject database 140 may store groups of accounts associated with subjects. Groups may have permissions based on group permission statements and/or access control lists, and members of the group may inherit permissions. For example, a marketing group may have access to one set of objects, while an engineering group may have access to another set of objects. The administrator group can change groups, change subject accounts, etc. Groups are also subjects identified by subject IDs.

In some embodiments, subject database 140 may be divided into multiple tables, indexes, and other data structures.

Object Storage

The function of content management system 110 is the storage of objects, which may be stored in object storage 142. An object is generally any entity that can be recorded in a file system. An object can be any digital data, including documents, collaborative objects, text files, audio files, image files, video files, web pages, executable files, binary files, directories, folders, zip files, playlists, albums, etc. Can be an object.

In some embodiments, objects may be grouped into collections, which may refer to folders containing multiple objects or multiple objects that are related or grouped by common attributes.

In some embodiments, object storage 142 is combined with other types of storage or databases to handle specific functions. While object storage 142 may store objects, metadata about objects may be stored in metadata database 146. Similarly, data regarding where objects are stored in object storage 142 may be stored in content directory 144. Additionally, data regarding changes, accesses, etc. may be stored in object database 148. Object database 148 may also include subject account identifiers that identify subject IDs that have access to objects.

In some embodiments, object database 148 may be divided into multiple tables, indexes, and other data structures.

Each of the various storages/databases, such as object storage 142, content directory 144, object database 148, and metadata database 146, can be configured with two or more such storages or databases and can be connected to many devices and locations. It can be distributed to Other configurations are also possible. For example, data from object storage 142, content directory 144, object database 148, and/or metadata database 146 may be combined into one or more object storages or databases, or further segmented into additional object storages or databases. can be converted into As such, content management system 110 may include more or less storage and/or databases than shown in FIG. 1.

In some embodiments, object storage 142 is associated with at least one object storage service 116 that includes software or other processor-executable instructions for managing the storage of objects, and that includes software or other processor-executable instructions for managing the storage of objects. Managing includes, but is not limited to, receiving objects for storage, preparing objects for storage, selecting storage locations for objects, retrieving objects from storage, etc. Not done. In some embodiments, object storage service 116 may divide objects into smaller chunks for storage in object storage 142. The location of each chunk that makes up the object may be recorded in the content directory 144. Content directory 144 may include a content entry for each object stored in object storage 142. A content entry may be associated with an object ID that identifies the object.

In some embodiments, each object and each chunk of objects may further be identified from a deterministic hash function. This method of identifying objects and chunks of objects may ensure that duplicates of objects are recognized as such, since a deterministic hash function will generate the same hash for all copies of the same object. This is because it outputs different hashes for different objects. Using this method, object storage service 116 may output unique hashes for different versions of an object.

Object storage service 116 may further specify or record the content path of the object within object database 148. The content path may include the name of the object and/or the folder hierarchy associated with the object. For example, the content path may include a folder or path to a folder in which the object is stored on the local file system on the client device. In some embodiments, the object database may store only the immediate ancestors or direct children of any object, allowing the full path from which the object is derived.

While objects may be stored in object storage 142 in blocks and not under a tree such as a directory structure, such a directory structure is a comfortable navigation structure for subjects. Object storage service 116 may define or record content paths for objects. Here, the "root" node of a directory structure can be any directory that has specific access privileges assigned to it, as opposed to a directory that inherits access privileges from another directory.

In some embodiments, a root directory may be mounted under another root directory to give the appearance of a single directory structure. This can occur if an account has access to multiple root directories. As mentioned above, the directory structure is merely a navigational structure that is comfortable for the subject, but is not correlated with the storage location of objects within object storage 142.

Although the directory structure in which an account views objects is not correlated to storage location in content management system 110, the directory structure is correlated to storage location on client device 150, depending on the file system used by client device 150. I can do it.

As mentioned above, a content entry within content directory 144 may further include the location of each chunk that makes up the object. More specifically, a content entry may include a content pointer that identifies the location within object storage 142 of the chunks that make up the object.

Object storage service 116 can reduce the amount of storage space required by identifying duplicate objects or blocks that make up an object or multiple versions of an object. Instead of storing multiple copies, object storage 142 may store a single copy of an object or block of an object, and content directory 144 may contain pointers or other information to link replicas to the single copy. mechanism.

Object storage service 116 further associates metadata with the object ID of the object that describes the object, object type, folder, file path, and/or relationship to various accounts, collections, or groups;
The information may be stored in metadata database 146.

Object storage service 116 may also store logs of data regarding changes, accesses, etc. in object database 148. Object database 148 may include an object ID for the object and optionally a description of the modification or access action, along with a timestamp or version number and any other related data. Object database 148 may further include pointers to blocks affected by the modification or object access. The object storage service undoes operations by using object version control to track changes to the object, different versions of the object (including branching version trees), and a history of changes that may be retrieved from the object database 148. ability.

Object Synchronization

Another function of content management system 110 is object synchronization with at least one client device 150. The client device(s) may take different forms and have different capabilities. For example, client device 150-1 is a computing device that has a local file system that is accessible by multiple applications residing thereon. Client device 150-2 is aware that the object is accessible only to a particular application or is accessible by permissions granted by a particular application, and that the object is typically stored either in an application-specific space or in the cloud. It is a computing device. Client device 150-3 is any client device that accesses content management system 110 via a web browser and accesses objects via a web interface. Although example client devices 150-1, 150-2, and 150-3 are depicted in form factors such as laptops, mobile terminals, or web browsers, the description thereof It should be understood that the device is not limited to For example, a mobile terminal such as client 150-2 may have a local file system that is accessible by multiple applications residing thereon, or client 150-2 may access content management system 110 via a web browser. I can do it. Therefore, form factor should not be considered limiting in considering the capabilities of client 150. One or more features described herein with respect to client device 150 may or may not be available on all client devices, depending on the device's particular capabilities - File Access models are one such capability.

In some embodiments, client device 150 may be communicatively connected to external hard drive 151.

In many embodiments, client devices are associated with an account on content management system 110, but in some embodiments, client devices can access content using shared links and do not require an account.

As mentioned above, some client devices may access content management system 110 using a web browser. However, client devices may also access content management system 110 using client applications 152 stored and executed on client devices 150. Client application 152 may include client synchronization service 156.

Client synchronization service 156 may communicate with server synchronization service 112 to synchronize changes to objects between client device 150 and content management system 110.

Client device 150 may synchronize content with content management system 110 via client synchronization service 156. Synchronization can be platform independent. That is, content may be synchronized across multiple client devices of different types, capabilities, operating systems, etc. Client synchronization service 156 monitors any changes (new, deleted, modified, copied, or moved) to objects in specified directories of the file system of client device 150 that are monitored by synchronization service 156. objects) can be synchronized.

Objects can be synchronized from client device 150 to content management system 110, and vice versa. In embodiments where the synchronization is from the client device 150 to the content management system 110, while the subject may manipulate objects directly from the file system of the client device 150, the client synchronization service 156 may manipulate files in the monitored folder. Specified directories on client device 150 may be monitored for changes to.

When client synchronization service 156 detects a write, move, copy, or deletion of content in a monitored directory, client synchronization service 156 may synchronize the changes to object storage service 116. In some embodiments, client synchronization service 156 includes some of the functions of object storage service 116, including the functions described above, such as dividing objects into blocks, hashing objects to generate unique identifiers, etc. can perform the following functions. Client synchronization service 156 may index content in client storage index 164 and save the results to storage index 164. Indexing may include storing a path plus an object identifier and storing a unique client identifier for each object. In some embodiments, client synchronization service 156 learns the object identifier from server synchronization service 112 and learns a unique client identifier from the operating system of client device 150.

Client synchronization service 156 may use storage index 164 to facilitate synchronization of at least some of the objects in client storage with objects associated with a subject account on content management system 110. For example, client synchronization service 156 may compare storage index 164 to content management system 110 and detect differences between content on client storage and content associated with the subject account on content management system 110. Client synchronization service 156 may then attempt to reconcile the differences by uploading, downloading, modifying, and deleting content on client storage as necessary. Object storage service 116 may store changed or new blocks for objects and update object database 148, metadata database 146, content directory 144, object storage 142, subject database 140, etc. as necessary.

When synchronizing from the content management system 110 to the client device 150, data regarding mounting, modifying, adding, deleting, and moving objects recorded in the object database 148 is sent to the client device 150 using the notification service 117. May trigger notifications. Once the client device 150 is notified of the change, the client device 150 may make a request for the changes listed in the object database 148 since the last synchronization point known to the client device. When client device 150 determines that it is out of synchronization with content management system 110, client synchronization service 156 requests the object block containing the changes and updates its local copy of the changed objects.

In some embodiments, the storage index 164 stores a tree data structure in which one tree reflects the most recent representation of the directory by the server synchronization service 112 while another reflects the most recent representation of the directory by client synchronization service 156. The client synchronization service may function to ensure that the tree structures match by requesting data from the server synchronization service 112 or by committing changes on the client device 150 to the content management system 110.

In some cases, client device 150 may not have an available network connection. In this scenario, client synchronization service 156 monitors linked collections for object changes and queues those changes for later synchronization to content management system 110 when network connectivity is available. sell. Similarly, a subject may manually start, stop, pause, or resume synchronization with content management system 110.

Client synchronization service 156 may synchronize all content associated with a particular subject account on content management system 110. Alternatively, client synchronization service 156 may selectively synchronize some of the objects associated with a particular subject account on content management system 110. Selectively synchronizing only some of the objects may conserve space on client device 150 and save bandwidth.

In some embodiments, client synchronization service 156 selectively stores portions of objects associated with a particular subject account and stores placeholder objects in client storage for the remaining portions of the objects. For example, the client synchronization service 156 may create a placeholder that has the same file name, path, extension, and metadata of a corresponding complete object on the content management system 110, but is missing data for that complete object. Can store objects. A placeholder object may be a few bytes or less in size, while a corresponding complete object may be significantly larger. After client device 150 attempts to access the object, client synchronization service 156 may retrieve the object's data from content management system 110 and provide the complete object to client device 150. This approach can provide significant space and bandwidth savings while still providing full access to the subject's objects on the content management system 110.

Collaboration features

Another function of content management system 110 is to facilitate collaboration between subjects. Collaborative features include object sharing, commenting on objects, collaborating on objects, instant messaging, providing presence, scene state information about objects, and the like.

Sharing

Content management system 110 may manage shared objects via sharing services 128. Sharing an object by providing a link to the object may include making the object accessible from any computing device that has network communication with content management system 110. However, in some embodiments, the link may be associated with access restrictions enforced by content management system 110 and Identity and Access Management (IAM) service 132. Sharing the content further includes sharing the content within the content management system 110 with at least one additional subject account (in addition to the original subject account associated with the object) such that each subject account has access to the object. This may include linking the content using the sharing service 128 for sharing with the user. Additional subject accounts may gain access to content by accepting the content, which is then accessible via web interface service 124 or linked to their accounts on client device 150. Directly accessible from within the associated directory structure. Sharing may be performed in a platform independent manner. That is, content may be shared across multiple client devices 150 of different types, capabilities, operating systems, etc. Content may also be shared across various types of subject accounts.

To share an object within content management system 110, sharing service 128 adds the team's subject ID or the subject ID of one or more subject accounts with the content item in object database 148 associated with the object. may also allow the added subject account(s) to access the object. Sharing service 128 may further prevent subject IDs from being allowed to access content items in object database 148 to limit the subject account's access to objects. Shared service 128 may record the object identifier, the subject identifier given access to the object, and the access level in object database 148. For example, in some embodiments, subject identifiers associated with a single content item may specify different permissions for each subject identifier with respect to the associated object.

In some embodiments, content management system 110 may include an access control list 145 that includes a complete description of access rights for individual objects. Access control lists for any individual object within the content management system may be derived from object database 148. In some embodiments, it is undesirable to maintain a persistent access control list 145 for individual objects, as the access control list 145 for individual objects can be derived as needed.

To share objects outside of content management system 110, sharing service 128 may generate custom network addresses, such as uniform resource locators (URLs), that allow any web browser to access the content without authentication. Objects or collections within management system 110 may be accessed. To accomplish this, sharing service 128 may include content identification data in the generated URL, which may later be used to properly identify and return the requested object. For example, sharing service 128 may include an account identifier and a content path or object identification code in the generated URL. In response to the selection of a URL, content identification data included in the URL may be sent to the content management system 110, which uses the received content identification data to identify the appropriate object. The object can be returned.

In addition to generating URLs, sharing service 128 may be configured to record in object database 148 that a URL to an object has been created. In some embodiments, an entry in object database 148 associated with an object may include a URL flag indicating whether a URL to the object has been created. For example, the URL flag may be a Boolean value initialized to 0 or false to indicate that no URL to the object has been created. After the shared service 128 generates the URL to the object, it may change the value of the flag to 1 or true.

In some embodiments, sharing service 128 may associate a set of permissions with a URL for an object. For example, when a subject attempts to access an object via a URL, sharing service 128 may provide a limited set of permissions to the object. Examples of restricted permissions include restrictions such as the subject not being able to download the object, not be able to save the object, not be able to copy the object, not be able to modify the object, etc. In some embodiments, restricted permissions are restricted only from the specified domain, i.e., only from within the corporate network domain, or from accounts associated with the specified domain, e.g., the corporate account (e.g., @acme. Contains restrictions that allow access to objects only by accounts associated with .com).

In some embodiments, sharing service 128 may be further configured to deactivate the generated URL. For example, each entry in object database 148 may include a URL active flag that indicates whether content should be returned in response to a request from the generated URL. For example, sharing service 128 may return the object requested by the generated link only if the URL active flag is set to one or true. In this way, by changing the value of the URL active flag, access to the object for which the URL has been generated can be easily restricted. This makes it possible to restrict a subject's access to a shared object without moving the object or deleting the generated URL. Similarly, shared service 128 may reactivate a URL by changing the value of the URL active flag to 1 or true again. This allows the subject to easily restore access to the object without having to generate a new URL.

In some embodiments, content management system 110 may specify a URL to upload the object. For example, a first subject with a subject account can request such a URL and provide the URL to a posting subject, which uses the URL to transfer the object to the first subject's subject account. Can be uploaded.

Team Service

In some embodiments, content management system 110 includes team services 130. Team service 130 may provide functionality for creating and managing defined teams of subject accounts. Teams can be created for companies that have sub-teams (e.g., business units, or project teams, etc.) and subject accounts assigned to teams and sub-teams, or teams can be created for any defined subject account. Can be created for groups. Team services 130 may provide a common shared space for teams, private subject account folders, and shared folders with limited access. Team services may also provide an administrative interface for administrators to manage collections and objects within a team, and may manage subject accounts associated with a team. Teams, sub-teams, and subject accounts are all given subject identifiers in the subject database 140, and the subject account's membership in the team is also recorded in the subject database 140.

IAM (Identity and Access Management) Service

In some embodiments, content management system 110 includes IAM service 132. IAM service 132 ensures that the subject account attempting to access the object has appropriate permissions to access the object. IAM service 132 may receive a token from client application 152 that may return the capabilities granted to the subject account in accordance with the request to access the namespace. For subject accounts with multiple levels of access (e.g., subject accounts with subject privileges and administrator privileges), IAM service 132 also provides explicit privilege escalation to avoid unintended actions by administrators. escalation) may be required.

Presence and Seen State

In some embodiments, a content management system may provide information about how subjects with whom an object is shared are interacting with or have interacted with the object. In some embodiments, content management system 110 may report that the subject with whom the object has been shared is currently viewing the object. For example, client collaboration service 160 may notify notification service 117 when client device 150 is accessing an object. Notification service 117 may then notify all other subject client devices that have access to the same object of the subject's presence of client device 150 for that object.

In some embodiments, content management system 110 may report a history of a subject's interactions with shared objects. Collaboration service 126 queries data sources, such as metadata database 146 and object database 148, to determine that the subject has saved the object, that the subject has not yet viewed the object, etc., and uses notification service 117. This status information may then be distributed to other subjects so that they can know who is currently viewing or has viewed the object, or who has modified the object.

Collaboration services 126 may facilitate comments associated with content even if the object does not originally support comment functionality. Such comments may be stored in metadata database 146.

Collaboration service 126 may originate and send notifications about the subject. For example, a subject may mention another subject in a comment, and collaboration service 126 may send a notification to that subject of being mentioned in the comment. Various other object events may trigger notifications, including object deletion, object sharing, and so on.

Collaborative services 126 may provide a messaging platform through which subjects can send and receive instant messages, voice calls, emails, and the like.

Collaboration Objects

In some embodiments, the content management service may further include a collaborative document service 134 that may provide an interactive object collaboration platform, allowing subjects to simultaneously create collaborative objects and make comments within collaborative objects. , may manage tasks within a collaborative object. A collaborative object can be a file that a subject can create and edit using a collaborative object editor, and can include collaborative object elements. Collaboration object elements may include a collaboration object identifier, one or more author identifiers, collaboration object text, collaboration object attributes, interaction information, comments, shared subjects, and the like. Collaborative object elements may be stored as database entities, allowing search and retrieval of collaborative objects. Multiple subjects may access, view, edit, and collaborate on collaborative objects at the same time or at different times. In some embodiments, this may be managed by requiring two subjects to access the object via a web interface, where they can work on the same copy of the object simultaneously.

Collaboration Companion Interface

In some embodiments, client collaboration service 160 may provide a native application companion interface for the purpose of displaying information related to objects being presented on client device 150. In embodiments where objects are accessed by a native application stored and executed on client device 150, the object resides in a specified location in the file system of client device 150, as managed by content application 152, and is accessed by the native application. may not provide a native way to display the coordination data described above. In such embodiments, client collaboration service 160 may detect that a subject has opened an object and may provide an overlay with additional information for the object, such as collaboration data. For example, additional information may include comments on the object, the state of the object, the activity of other subjects who have previously or currently viewed the object. Such an overlay may alert the subject that changes may be lost due to other subjects currently editing the object.

In some embodiments, one or more of the services or storage/databases described above may be accessed using public or private application programming interfaces.

A particular software application may access object storage 142 via an API on behalf of a subject. For example, a software package, such as an application, running on client device 150 may require a subject to provide authentication credentials in order to read, write, create, delete, share, or otherwise manipulate content. If provided, API calls may be made programmatically directly to the content management system 110.

A subject may view or manipulate content stored in the subject account via a web interface generated and provided by web interface service 124. For example, a subject may navigate within a web browser to a web address provided by content management system 110. Changes or updates to content within object storage 142 made via the web interface, such as uploading a new version of an object, may be communicated back to other client devices associated with the subject's account. For example, multiple client devices, each with its own client software, may be associated with a single account, and objects within the account may be synchronized between each of the multiple client devices.

Client device 150 may connect to content management system 110 on behalf of a subject. A subject may directly interact with client device 150, for example, when client device 150 is a desktop or laptop computer, a telephone, a television, an internet-of-things device, and the like. Alternatively or additionally, client device 150 may act on behalf of a subject without the subject having physical access to client device 150, eg, if client device 150 is a server.

Some features of client device 150 are enabled by applications installed on client device 150. In some embodiments, the application may include content management system-specific components. For example, a content management system-specific component may be a standalone application 152, one or more application plug-ins, and/or a browser extension. However, a subject may interact with content management system 110 via a third party application, such as a web browser, that resides on client device 150 and is configured to communicate with content management system 110. . In various implementations, client-side application 152 may present a subject interface (UI) for subjects to interact with content management system 110. For example, a subject may interact with content management system 110 through a file system explorer integrated with the file system or through a web page displayed using a web browser application.

In some embodiments, client application 152 may be configured to manage and synchronize content for two or more accounts on content management system 110. In such embodiments, client application 152 may remain logged into multiple accounts and provide regular services to the multiple accounts. In some embodiments, each account may appear as a folder within a file system, and all objects within that folder may be synchronized with content management system 110. In some embodiments, client application 152 may include a selector to select one of the multiple accounts to be the primary or default account.

Third Party Services

In some embodiments, content management system 110 may include functionality for interfacing with one or more third party services, such as a workspace service, an email service, a task service, etc. In such embodiments, content management system 110 interacts with third-party services to bring functionality or data from those third-party services to various subject interfaces provided by content management system 110. may be provided with login credentials for a Subject's account at a Third Party Service.

Although specific components of content management system 110 are presented, it is understood that the architectural configuration of system 100 is only one possible configuration and that other configurations with more or fewer components are possible. , as understood by those skilled in the art. Furthermore, a service may have more or less functionality, and may even include functionality described as involving another service. Additionally, features described herein with respect to one embodiment may be combined with features described with respect to another embodiment.

Although specific components are presented in system 100, it is understood that the architectural configuration of system 100 is only one possible configuration and that other configurations with more or fewer components are possible. If you are a business owner, please understand.

FIG. 2 illustrates an example client synchronization service according to some embodiments. Client synchronization service 156 may be implemented on client device 150 of FIG. However, in some embodiments, client synchronization service 156 may be implemented on another computing device. Client synchronization service 156 is configured to synchronize changes to objects between content management system 110 and client device 150 on which client synchronization service 156 is executed.

Client synchronization service 156 may include file system interface 205, server interface 210, tree storage 220, planner 225, and scheduler 230. Additional or alternative components may also be included.

File system interface 205 is configured to process changes to objects on local file system 270 of client device 150 and to update local tree 250 or make changes to local file system 270 . For example, file system interface 205 may detect changes to objects in monitored directories on local file system 270 of client device 150. Changes may also be made and detected via client application 152 of FIG. File system interface 205 may update local tree 250. Updates to local tree 250 may be made based on changes to objects on the client device (new, deleted, modified, copied, renamed, or moved objects).

Server interface 210 is configured to support processing remote changes to objects in content management system 110 and updating remote tree 210. For example, server interface 210 may communicate with server synchronization service 112 to synchronize changes to objects between client device 150 and content management system 110. Changes to objects in content management system 110 (new, deleted, modified, copied, renamed, or moved objects) may be detected and the changes in content management system 110 reflected. Updates may be made to remote tree 210 at any time. Server interface 210 is further configured to support communication of local changes to objects in local file system 270 to server synchronization service 112 to update object database 148.

Tree storage 220 is configured to store and maintain tree data structures used by client synchronization service 156. For example, tree storage 220 may store local tree 250, synchronized tree 235, and remote tree 210. In some embodiments, tree storage 220 stores tree data structures in persistent memory (e.g., hard disk or other secondary storage) as well as main memory (e.g., RAM or other (primary storage device). For example, upon startup of the client device or client synchronization service 156, the tree data structure may be retrieved from persistent memory and loaded into main memory. Tree storage 220 may access and update the tree data structure on main memory, and before the client device or client synchronization service 156 is shut down, tree storage 220 may permanently store the updated tree data structure. May be stored in memory.

Remote tree 210 represents server state or the state of objects stored remotely from a client device (eg, on a server of a content management system). Local tree 250 represents the file system state or the state of corresponding objects stored locally on the client device. Synchronization tree 235 represents the merge base for local and remote trees. A merge base may be thought of as a common ancestor of a local tree and a remote tree, or the last known state of synchronization between a local tree and a remote tree.

Each tree data structure (eg, remote tree 210, synchronization tree 235, or local tree 250) may include one or more nodes. Each node within the tree data structure may represent an object (eg, file, document, folder, etc.). Each node in the tree data structure may include data such as, for example, a directory object identifier that specifies the object identifier of the object's parent node, the object's object name, the object's object identifier, and the object's metadata.

Planner 225 is configured to detect differences between a server state associated with content management system 110 and a file system state associated with client device 150 based on the state of the tree data structure. For example, planner 225 may determine whether there are differences between remote tree 210 and synchronization tree 235. The difference between remote tree 210 and synchronization tree 235 is that an action performed remotely on one or more objects stored in content management system 110 has caused server state and file system state to become unsynchronized. shows. Similarly, planner 225 may further determine whether there are differences between local tree 250 and synchronization tree 235. The difference between local tree 250 and synchronization tree 235 is that actions performed locally on one or more objects stored in local file system 270 on client device 150 can be performed on server state and file system state. Indicates that it has been made asynchronous. If a difference is detected, planner 225 generates a set of operations to synchronize the tree data structures.

In some scenarios, the set of behaviors generated based on the differences between the remote tree and the sync tree may conflict with the set of behaviors generated based on the differences between the local tree and the sync tree. sell. Planner 225 may further be configured to combine two sets of actions into a single integrated action plan.

Scheduler 230 is configured to obtain the generated operation plans and manage the execution of those operations. According to some embodiments, scheduler 230 converts each operation in the operation plan into a sequence of one or more tasks that need to be executed to perform the operation. In some scenarios, some tasks may become obsolete or no longer relevant. Scheduler 230 is configured to identify those tasks and cancel those tasks.

If differences exist between local tree 250 and synchronized tree 235, changes need to be synchronized to content management system 110. To synchronize local file system 270 changes to content management system 110, the client synchronization service may commit an intent to the server synchronization service 112 that is related to a particular synchronization operation. To commit an intent, client synchronization service 156 on client device 150 records the intent to commit operations on client device 150. Client synchronization service 156 may record an intent to permanently commit an operation on disk or memory of client device 150 to track pending commits. Client device 150 may store dirty commit records and tracking modifications until an event triggers removal of a pending commit, such as a failure or success. Client synchronization service 156 further commits the operation to server synchronization service 112 by sending a message to server synchronization service 112 requesting to commit the operation.

Server synchronization service 112 may send a return message indicating whether the commit to content management system 110 was successful or an error. When the client synchronization service 156 learns that the commit was successful, the client synchronization service 156 updates the remote tree 610 and the synchronization tree 620 to include the synchronized operations and the intent to commit the operations from the client device 150. Clear.

Client application 152 may learn of changes that exist at the server by requesting information about events that occur on objects recorded in object database 148 since the last synchronization time known to the client device. In some embodiments, client synchronization service 156 makes requests for updated information periodically or in response to receiving notifications of potential changes. When changes occur to accounts in the content management system, server synchronization service 112 may send information regarding the performed operations to client synchronization service 156, which may update remote tree 215. Client synchronization service 156 may then detect a difference between remote tree 215 and synchronization tree 235 indicating that local file system 270 needs to be updated. Planner 225 may identify operations required to update local file system 270, and server interface 210 may request any data, such as blocks making up objects, etc., from content management system 110. sell.

Client synchronization service 156 may bring the system into a synchronized state by updating local file system 270, local tree 250, and synchronization tree 235. Additionally, client synchronization service 156 may indicate that the client application is current at least up to the last synchronization time by storing information identifying the synchronization time associated with information received from object database 148. In some embodiments, the last synchronization time may be stored as part of a cryptographically signed cursor associated with a row in object database 148 and received from content management system 110. The next time the client synchronization service requests updated information, it provides a cursor to identify the point in object database 148 to begin reading.

Anchor Object

In some embodiments, content management system 110 may include functionality to generate anchor objects for external directories that are external to the monitored directory on client device 150. An anchor object is an object that has dedicated attributes. Client application 152 may recognize an anchor object as an object that points to a directory that is external to the directory monitored by client synchronization service 156. For example, FIG. 2 shows an anchor object 271 in a directory monitored by client synchronization service 156, where anchor object 271 points to external directory external hard drive 151. Although anchor object 271 is shown as pointing to external hard drive 151 in FIG. 2, anchor object 271 points to other directories on client device 150 that are outside of the directories monitored by synchronization service 156. Please understand that there may be cases.

Anchor objects can be used to synchronize the content of external directories represented by anchor objects to content management system 110. In some embodiments, the anchor object may be associated with a property that directs the client synchronization service to synchronize objects in the external directory directly without first being stored on the client device 150.

From the perspective of content management system 110, an external directory represented by an anchor object may be treated as if the external directory were located within the directory that includes the anchor object. An anchor object may be stored as a directory within the monitored directory and may appear with objects located below it, as shown in remote tree 215.

However, from the perspective of the client synchronization service 156, the anchor object has specialized attributes that change some characteristics of how it is represented in the local tree 250 and synchronization tree 235, and in the external directory. Some aspects of synchronization of stored objects may be changed. A representation of a monitored directory may be stored in a local tree structure 250 that represents the file system structure of objects within the monitored directory, including anchor objects 271 . Anchor object 271 is represented in the local tree structure as a file or dedicated object that has a flag as part of its dedicated attributes to indicate that it is an anchor object. Similarly, any objects subordinate to an anchor object may also appear in local tree 250 or synchronization tree 235 with a flag or dedicated attribute to indicate that they are part of an external directory.

In some embodiments, the anchor object's dedicated attributes are extended attributes or final data streams that describe attributes of the associated external directory. For example, the dedicated attribute may be an Xattr that stores the location information of the associated external directory as a Binary Large Object (BLOB). Location information includes, but is not limited to, directory IDs, inode references, device IDs, object IDs, unique IDs (UUIDs), target locations, paths, and the like. The dedicated attributes may serve as a source of truth for the identity and location of the external directory and its corresponding content.

In some embodiments, client synchronization service 156 may recognize anchor objects by detecting the presence of dedicated attributes. After determining that the object is a valid anchor object, client synchronization service 156 may read the contents of the associated external directory as indicated by the dedicated attributes. Client synchronization service 156 may then communicate with server synchronization service 112 to synchronize content items stored on external directories to content management system 110. Such synchronization of external directories may occur periodically or when certain file events occur. With respect to FIGS. 3A and 3B, such a process is described in more detail.

In some embodiments, dedicated attributes, such as Xattr, may allow the content management system to intercept certain user operations on the anchor object and perform predetermined actions in response. This process is explained in more detail with respect to FIGS. 3A and 3B. For example, if a user double-clicks an anchor with an Xattr that includes the UUID of an external drive, and the external drive is accessible, the content management system may present the content of the external drive via the user interface. If the external drive in Xattr is not accessible, the content management system may present the external drive's corresponding synchronized content stored on the content management system.

In some embodiments, after determining that the object is a valid anchor object, the server synchronization service 112 reads the anchor object's dedicated attributes and performs in-memory processing based on the dedicated attributes. You can create maps. The in-memory map may be a source of truth in memory, such as local memory of client device 150. In such embodiments, the client synchronization service 156 uses an in-memory map to convert the external directory's UUID to a content management system path within the local tree structure, thereby tracking the contents of the external directory. sell. Such in-memory maps are updated periodically or on specific file events. With respect to FIG. 4, such a process will be explained in more detail.

From the perspective of a user of client device 150, anchor objects may be represented as folders through the user interface of client device 150. When a user performs an operation on an anchor object via the user interface on client device 150, the user experience is the same as interacting with any other folder on the user interface. For example, a user may open an anchor object to view its corresponding content, delete the anchor object, move the anchor object, or rename the anchor object. With respect to FIG. 5, such a process will be explained in more detail.

The introduction of anchor objects provides several improvements over existing techniques for synchronizing content items stored external to a client device to a content management system. First, external content can be synchronized directly from an external location to the content management system without first having to be stored locally on the client device. Second, anchor objects provide a consistent user experience for interacting with external directories regardless of whether the external directories are accessible to the client device.

FIG. 3A shows an example method 300 for synchronizing external locations of client devices. Although the example method 300 depicts a particular sequence of operations, the sequence may be modified without departing from the scope of this disclosure. For example, some of the illustrated operations may be performed in parallel or in different sequences that do not substantially affect the functionality of method 300. In other examples, different components of an example device or system implementing method 300 may perform functions substantially simultaneously or in a particular sequence.

At act 302, the content management system client application 152 running on the client device may discover an external directory that is external to the synchronized directory. For example, client application 152 shown in FIG. 1 may discover an external directory that is external to the synchronization directory, such as a directory monitored by client synchronization service 156 on client device 150. The external directory can be an external hard drive connected to the client device, a network drive accessible to the client device, a folder on the client device, a file object on the client device, a camera connected to the client device, etc.

At act 304, the content management system client application 152 may render the external directory within a graphical user interface. In a first example, client application 152 may display a prompt presenting a message informing the user that an external directory is available for synchronization. In a second example, the representation of the external directory in the graphical user interface may be an icon representing the external directory within a list of accessible folders or external drives on the client device 150. This operation will be described in more detail with respect to FIGS. 6A and 6B.

At act 306, the content management system client application 152 may accept a selection of an external directory representation from a user of the client device 150. This operation will be described in more detail with respect to FIGS. 6A and 6B.

At act 308, the content management system client application 152 may present an option to register the external directory for synchronization in response to accepting the selection of the external directory representation. This operation will be described in more detail with respect to FIGS. 6A and 6B.

In act 309, the content management system client application 152 presents an option to register the external directory for synchronization in response to accepting the selection of the external directory representation in act 306 or in act 308. along with an option to exclude objects on external directories from synchronization.

At act 310, the content management system client application 152 may create a link to an external directory. In a first example, a link to an external directory includes a dedicated attribute that identifies the link as pointing to an external directory to be synchronized. Directory attributes include, but are not limited to, directory ID, inode reference, device ID, object ID, UUID, target location, path, and the like. In the second example, the link is a custom object type called an anchor object. As discussed above with respect to FIG. 1, an anchor object is an object that has dedicated attributes. An anchor object is recognized by a client application as an object that identifies the anchor object as pointing to an external directory to be synchronized and describes attributes of the directory. In a third example, the link is a symbolic link or a shortcut.

In some embodiments, once the link is created in operation 310, a content management system client application may recursively subscribe to file events in the external directory represented by the anchor object. For example, client application 152 may detect file events in the external directory represented by the anchor object after expiration of a certain period of time, such as hourly, daily, or monthly. Client application 152 may use the detected file events of the external directory in further achieving synchronization of the client device's external location.

In act 312, client application 152 may store link 271 created in act 310 to a synchronized directory on client device 150.

At act 314, client application 152 may represent stored links 271 in the synchronized directory as selectable icons. For example, a link may be represented on the user interface as a folder, external drive, camera, file object, or custom icon.

At act 316, client application 152 may access the external directory via a link representing the external directory.

At act 318, the client application 152 shown in FIG. 1 may determine whether the external directory is a valid location after accessing the external directory. In a first example, determining that the external directory is a valid location includes determining that the external directory exists and is accessible. In a second example, determining that the external directory is a valid location includes determining that the external directory is in a supported format. Supported formats may be disc formats that are readable by client applications. Supported formats may be disc formats that support extended attributes. Examples of external drive formats include FAT32 and exFAT. In some embodiments, a format may not be fully supported if the format does not support extended attributes or other mechanisms for storing required metadata. In some embodiments, the technology may still be able to function in a limited manner. Unsupported formats may result in reduced functionality, such as unidirectional synchronization or batch backup of external directories.

If the client application 152 determines in act 318 that the external directory is a valid location, the process may proceed to act 320. At act 318, if the client application 152 determines that the external directory is not a valid location, the process may terminate.

At act 320, a client application of the content management system may discover at least one object on the external directory. For example, client application 152 shown in FIG. 1 may discover at least one object on an external directory. The client application 152 shown in FIG. 1 can read metadata about the contents of the external directory and can process each object in the external directory to convert the contents of each object into a hashed block. In one example, the hashed block is temporarily stored in memory of client device 150.

In some embodiments, a client application can read metadata associated with the contents of an external drive and, after expiration of a period of time, convert the contents of each object into a hashed block in the external directory. can process each object.

At act 322, the client synchronization service 156 shown in FIG. 1 synchronizes at least one object on the external directory to the content management system without first storing the at least one object on the client device's internal hard drive. The server synchronization service 112 may communicate with the server synchronization service 112. In one example, a content management system is configured to synchronize content in a synchronized directory bidirectionally, but an external directory synchronization means that changes made to objects in the external directory are not synchronized to the content management system. However, it is a one-way synchronization so that changes made to objects represented on the content management system's cloud storage are not synchronized to an external directory.

In some embodiments of act 322, the detection of file events on some external directories may be unreliable, so the client application may trigger synchronization after the expiration of a certain period of time. For example, the client synchronization service 156 shown in FIG. 1 may trigger synchronization after the expiration of a certain period of time. Although it may not be reliable in some situations, it is also possible to trigger a synchronization after a file event is detected in an external directory. For example, the client synchronization service 156 shown in FIG. 1 may trigger synchronization after a file event is detected in an external directory. Additionally, synchronization may be triggered in response to receiving user input requesting synchronization. For example, client synchronization service 156 shown in FIG. 1 may trigger synchronization in response to receiving user input requesting synchronization.

As discussed with respect to FIG. 1, synchronizing an object may include dividing the object into blocks and subjecting the blocks to a hash function to obtain a block identifier before sending the blocks to content management system 110. can be inserted. The block identifier may be used to determine whether content management system 110 has already stored this block. If the content management system does not already own the block, the block is sent to the content management system for storage. In one example of operation 322, synchronization further includes transmitting the hashed block, temporarily stored in memory, to content management system 110.

At act 324, client application 152 may provide a user interface effective to accept user input to select objects in the external directory to be excluded from synchronization.

In some embodiments, act 324 may be performed before or concurrently with act 322.

At act 326, client device 150 may store selected objects to be excluded from synchronization in a hidden object.

At act 328, the client application 152 shown in FIG. 1 may exclude the selected object from synchronization by the client synchronization service 156 of the client application 152 if the selected object is referenced in a hidden object.

In some embodiments, instead of performing acts 324, 326, and 328, client application 152 provides a user interface effective for accepting user input to select objects in the external directory to synchronize. I can do it. For example, a user may select a set of subfolders from an external drive to synchronize instead of all folders from the external drive. In another example, a user may select a set of subfolders from other drives or volumes associated with client device 150 to synchronize.

FIG. 3B illustrates an example method 350 for accessing a client device's external location through selection of an anchor object. Although the example method 350 depicts a particular sequence of operations, the sequence may be modified without departing from the scope of this disclosure. For example, some of the illustrated operations may be performed in parallel or in different sequences that do not substantially affect the functionality of method 350. In other examples, different components of an example device or system implementing method 350 may perform functions substantially simultaneously or in a particular sequence.

At act 330, client application 152 may accept, through a user interface, a selection of stored links representing external directories.

At act 332, client application 152 shown in FIG. 1 may determine whether the external directory is accessible.

If, at act 332, client application 152 determines that the external directory is accessible, the process may proceed to act 334.

At act 334, client device 150 may provide access to an external directory.

If, at act 332, client application 152 determines that the external directory is not accessible, the process may proceed to act 336.

At act 336, the content management system's client application may provide access to the synchronized content of the external directory within the content management system's web interface at step 334. For example, the client application 152 shown in FIG. 1 may provide access to synchronized content of an external directory within a web interface of the content management system if the external directory is not accessible. In this example, client application 152 is providing access to synchronized content in the external directory stored in content management system 110 rather than content stored in the external directory.

In some embodiments, a dedicated attribute of an anchor object, such as can be made possible. For example, if the user double-clicks an anchor with an Xattr that includes the UUID of the external drive, and the external drive is accessible, client application 152 may present the contents of the external drive through the user interface in operation 334. If the external drive in Xattr is not accessible, the client application 152 may present the external drive's corresponding synchronized content stored on the content management system at operation 336.

In some embodiments, a content management system's server synchronization service may convert synchronized copies of external directories into link containers. For example, if synchronization of an external directory fails, server synchronization service 112 may convert a synchronized copy of the external directory stored in content management system 110 to a link container. Once such conversion occurs, nodes representing external directories on the local tree are set to an ignored state, which causes content management system 110 and client application 152 to ignore further changes on such nodes. I will do it. Nodes representing external directories on the remote tree are set to a hidden state so that synchronized copies of such external directories on the remote tree are not shown on the content management system 110 user interface. nodes will be hidden. Other example situations that may trigger this conversion process include external directory content taking too long to read, system failure on client device 150, and external directory synchronization on content management system 110. Examples include, but are not limited to, deleted copies being deleted, or external directories becoming inaccessible to client device 150 while synchronization is occurring.

FIG. 4 illustrates an example method 400 for generating anchor objects. Although the example method 400 depicts a particular sequence of operations, the sequence may be modified without departing from the scope of this disclosure. For example, some of the illustrated operations may be performed in parallel or in different sequences that do not substantially affect the functionality of method 400. In other examples, different components of an example device or system implementing method 400 may perform functions substantially simultaneously or in a particular sequence.

At act 410, client application 152 may create an anchor object for the external directory. As discussed above with respect to FIGS. 1 and 3A, an anchor object is an object that has specialized attributes such that a client application can recognize the anchor object as an object that points to an external directory outside of the directory containing the anchor object. . In this example, the client application treats the external directory as if it were located within the directory that contains the anchor. Dedicated attributes are extended attributes or final data streams that describe the attributes of the directory. Directory attributes include, but are not limited to, directory ID, inode reference, device ID, object ID, UUID, target location, path, and the like.

In some embodiments, the directory that stores the anchor is a directory that is monitored by the client synchronization service 156 and whose content is synchronized to the content management system.

At act 420, client synchronization service 156 may recognize the anchor object. In this example, anchor objects are recognized by the presence of dedicated attributes.

At act 430, client synchronization service 156 may read the dedicated attributes of the anchor object. In this example, client synchronization service 156 may read metadata about the contents of the external directory and process each object in the external directory to convert the contents of each object into a hashed block.

At act 440, the client application's synchronization service 156 may use the anchor object's dedicated attributes to determine the external folder information. For example, client synchronization service 156 may use specialized attributes of the anchor object to determine the content, location information, or other information of an external folder associated with an external directory.

At act 450, client synchronization service 156 may create an in-memory map of the external directory based on the proprietary attributes to convert the external directory's device UUID to a content management system path within the local tree. The dedicated attributes serve as a source of truth for identity and location.

At act 460, client synchronization service 156 may read the contents of the external directory.

At act 460, client synchronization service 156 may synchronize at least one object on the external directory to the content management system. In this example, the user may have options regarding which objects should and should not be synchronized. In some embodiments, the synchronization of act 460 is unidirectional from the external directory to content management system 110. In some embodiments, synchronization operations are bidirectional between the external directory and content management system 110.

FIG. 5 illustrates an example method 500 for processing and synchronizing external directories with a content management system server. Although the example method 500 depicts a particular sequence of operations, the sequence may be modified without departing from the scope of this disclosure. For example, some of the illustrated operations may be performed in parallel or in different sequences that do not substantially affect the functionality of method 500. In other examples, different components of an example device or system implementing method 500 may perform functions substantially simultaneously or in a particular sequence.

At act 505, server synchronization service 112 may receive synchronization of an anchor object by a content management system from a first client device. In one example, as described above with respect to FIGS. 1, 3A, and 4, the anchor object is an object that has dedicated attributes, and the anchor object is an external directory reachable by the first client device by the content management system. It is recognized as an object pointing to . In this example, the external directory is external to the directory on the first client device that contains the anchor object.

At act 510, the web interface service 124 shown in FIG. 1 may represent the anchor object as a folder within a directory that includes the anchor object. For example, child objects of an anchor object may also be represented as being within a path consisting of a directory containing the anchor object. Anchor objects and child objects are browsable and viewable on the content management system's web server. In another example, the anchor object and child objects are browsable and viewable on a file browser of a client device, such as a smartphone or personal computer.

In some embodiments, an anchor object and its child objects are configured for unidirectional synchronization, but the content management system supports bidirectional synchronization of objects by default. However, those skilled in the art will also understand that the anchor object and its child objects may also be configured for two-way synchronization.

At act 515, the web interface service 124 shown in FIG. 1 may accept a selection of a child object in the path of the anchor object via a web server of the content management system.

At act 525, web interface service 124 may accept edits to the child object via the content management system's web server. In some embodiments, such editing of child objects may occur on a client application on a second client device.

At act 530, the server synchronization service 112 shown in FIG. 1 may determine that the child object is configured for unidirectional synchronization. For example, server synchronization service 112 may determine that a child object is configured for unidirectional synchronization by determining that the child object is in a path that has the anchor object as an ancestor in the object path. In another example, the server synchronization service 112 determines whether the child object is configured for one-way synchronization by determining that the child object is associated with a dedicated attribute that indicates that the child object is configured for one-way synchronization. It can be determined that it is set to .

At act 535, web interface service 124 may provide a warning that the child object is configured for unidirectional synchronization.

At act 540, web interface service 124 may accept input from the user confirming that the user wishes to synchronize edits.

At act 545, the server synchronization service 112 shown in FIG. 1 may create a copy of the child object that includes the edits. In this example, a copy of the child object is initially stored on content management system 110 under a directory associated with client device 150 (e.g., a user account directory, or other directory) other than an external directory. sell.

At act 550, server synchronization service 112 may synchronize a copy of the child object to a directory that supports two-way synchronization. In this example, server synchronization service 112 may not synchronize the copy to an external directory.

At act 550, server synchronization service 112 may synchronize the anchor object to the second client device. In one example, the anchor object is represented as a link placeholder on the second client device's file system. In a second example, when selected on a second client device, the link placeholder is configured to cause the second client device to direct a web browser to a web server of the content management system.

In some embodiments, edits are not synchronized to the child object's master because the child object is configured for unidirectional synchronization. For example, if the child object is a child object of an external drive, represented by an anchor object, edits to the child object received from the content management system are not synchronized to the original of the child object stored on the external drive. Instead, example method 500 facilitates preserving edits within a content management system by creating and storing another copy of a child object using the edits.

FIG. 6A shows an example graphical user interface, according to some embodiments. The graphical user interface includes a window 602, a local sync folder 610, and a web interface 620. Window 602 is displayed in response to an external drive connected to client device 150. Window 602 includes selectable interface elements 604 and 606. Local sync folder 610 is a directory on client device 150 that is monitored by client application 152 associated with content management system 110. Content in local sync folder 610 may be synchronized with content management system 110. In this example, local sync folder 610 is empty.

Web interface 620 presents a web view of content management system 110. In this example, web interface 620 includes a file selection interface 622 that shows files stored on content management system 110.

As discussed with respect to FIG. 3A, the client application 152 of the content management system 110 may present the external drive as a selectable interface element 604 representing the external drive. Client application 152 may accept selections of selectable interface elements 604 from a user. Client application 152 may further present an option (selectable interface element 606) to register an external drive for synchronization with content management system 110.

FIG. 6B depicts another example graphical user interface, according to some embodiments. As described with respect to FIG. 3A, when the user selects both selectable interface elements 604 and 606, the client synchronization service 156 creates an external directory without first storing the content on the internal hard drive of the client device 150. Communication may be initiated with a server synchronization service 112 to synchronize the content on the content management system 110. Details of synchronization are explained in FIG. 3A.

After synchronization is complete, interface elements appear in the graphical user interface shown in FIG. 6B. For example, interface element 632 appears in local sync folder 610 and interface element 634 appears in file selection interface 622 of web interface 620. Interface elements 630, 632, and 634 all represent external drives at these different locations. In this example, interface element 632 is an anchor object as described with respect to FIG. A user may access an external drive by selecting any one of interface elements 630, 632, and 634. This user interface design provides a consistent user experience when interacting with an external drive, even if the contents of the external drive are not stored on the internal hard drive of client device 150.

FIG. 6C depicts another example graphical user interface, according to some embodiments. The graphical user interface includes window 640. Window 640 includes interface elements 642. In this example, the user may select interface element 642 and then select any local folder, such as local folder 644, to be backed up to content management system 110. To accept the selection of local folders, client application 152 may present another window containing all local folders after the user selects interface element 642.

FIG. 6D shows another example graphical user interface, according to some embodiments. After the selection of a local folder, such as local folder 644, is accepted, client synchronization service 156 initiates communication with server synchronization service 112 to synchronize the content on the selected local folder to content management system 110. sell. Details of synchronization are discussed in detail with respect to FIG. 3A.

After synchronization is complete, an interface element 646 representing local folder 644 appears in local synchronization folder 610. Also, an interface element 648 appears in the file selection interface 622 of the web interface 620. A user may access the contents of local folder 644 by selecting any one of interface elements 644, 646, and 648.

FIG. 7 illustrates an example computer system 700 for implementing portions of this disclosure. For example, example computer system 700 may execute a client application to implement the present disclosure.

Exemplary computer system 700 includes a processor 705 , memory 710 , graphical device 715 , network device 720 , interface 725 , and storage device 730 operably connected via bus 735 . Processor 705 reads machine instructions (e.g. reduced instruction set (RISC), complex instruction set (CISC), etc.) that are loaded into memory 710 via a bootstrapping process and executes them within the framework provided by the OS. Runs an operating system (OS) for running the . For example, processor 705 may execute an application that executes an application provided by Windows, a graphical framework such as Windows Presentation Foundation (WPF), Windows User Interface (WinUI), or a cross-platform user interface such as Xamarin or QT. . In other examples, processor 705 may execute applications written for a sandbox environment, such as a web browser.

Processor 705 controls memory 710 to store instructions, user data, OS content, and other content that cannot be stored within processor 705 (eg, in various caches). Processor 705 may further control a graphical device 715 (eg, a graphical processor) that outputs graphical content to display 740. In some examples, graphical device 715 may be integrated within processor 705. In yet another example, display 740 can be integral to computer system 700 (eg, laptop, tablet, phone, etc.).

Graphical device 715 may be optimized to perform floating point operations, such as graphical calculations, and may be configured to perform other operations on behalf of processor 705. For example, it is controlled by instructions that perform mathematical operations optimized for floating point numbers. For example, processor 705 may assign instructions to graphical device 715 for operation optimized for graphical device 715. For example, graphical device 715 may perform operations related to artificial intelligence (AI), natural language processing (NLP), and vector operations. The results may be returned to processor 705. In another example, an application executing on processor 705 may provide instructions to cause processor 705 to request graphical device 715 to perform an operation. In other examples, graphical device 715 may return processing results to another computer system (ie, distributed computing).

Processor 705 further includes a plurality of wireless channels 745 and at least one communication standard (e.g., Wi-Fi (i.e., 802.11ax, 802.11e, etc.), Bluetooth®, various wireless channels provided by the Third Generation Partnership Project). Standards (eg, 3G, 4G, 5G), or satellite communication networks (eg, Starlink)) may be used to control network devices 720 for transmitting and receiving data. Network device 720 may wirelessly connect to network 750 to connect to a server 755 or other service provider. Network device 720 may further be connected to network 750 via a physical (ie, circuit) connection. Network device 720 may also connect directly to local electronic device 760 using point-to-point (P2P) or short-range wireless connections.

Processor 705 may further control an interface 725 that connects with external devices 770 for bidirectional or unidirectional communication. Interface 725 is any suitable interface that forms a circuit connection and may be implemented by any suitable interface (eg, Universal Serial Bus (USB), Thunderbolt, etc.). External device 765 can receive data from interface 725 to process the data or perform functions for different applications executing on processor 705. For example, external device 765 may include another display device, a musical instrument, a computer interface device (e.g., keyboard, mouse, etc.), an audio device (e.g., analog-to-digital converter (ADC), digital-to-analog converter (DAC)), content It can be a storage device for storage, an authentication device, an external network interface (eg, a 5G hotspot), a printer, etc.

Claims (20)

A method,
receiving a communication from a first client device for synchronizing an anchor object by a content management system, wherein the anchor object is provided to the content management system in an external directory reachable by the first client device; an object having attributes that cause the anchor object to be recognized as pointing to an object, the external directory being external to a directory on the first client device that includes the anchor object;
representing the anchor object as a folder within the directory containing the anchor object on a web server of the content management system, wherein child objects of the anchor object are within a path below the anchor object; What is expressed as something,
synchronizing the anchor object on the first client device, the anchor object being represented as a link placeholder on a file system of the first client device;
including methods. The method according to claim 1 ,
The anchor object and the child object are browsable and viewable on the web server of the content management system. 2. The method of claim 1 , comprising synchronizing the anchor object to a second client device, the anchor object being located at a second link place on a second file system of the second client device. the external directory is not reachable by the second client device. 4. The method according to claim 3 ,
The method, wherein the link placeholder, when selected at the second client device, is configured to cause the second client device to direct a web browser to the web server of the content management system. The method according to claim 1 ,
The method, wherein the anchor object and the child object are configured for unidirectional synchronization. The method according to claim 1 ,
accepting, via the web server of the content management system, a selection of child objects within the path of the anchor object;
providing a warning that the child object is configured for unidirectional synchronization;
including methods. The method according to claim 1 ,
accepting edits to child objects via the web server of the content management system;
determining that the child object is configured for unidirectional synchronization;
providing a warning that the child object is configured for unidirectional synchronization;
accepting input confirming that the user account wishes to synchronize said edits; and
including methods. 8. The method according to claim 7 ,
creating a copy of the child object containing the edit;
synchronizing the copy of the child object in a directory that supports bidirectional synchronization and that is different from the external directory;
including methods. 8. The method according to claim 7 ,
Determining that the child object is configured for unidirectional synchronization includes:
A method comprising determining that the child object is a child object of the anchor object. 8. The method according to claim 7 ,
Determining that the child object is configured for unidirectional synchronization includes:
A method comprising determining that the child object is associated with an attribute indicating that the object is configured for unidirectional synchronization. a non-transitory computer-readable medium containing instructions that, when executed by a computing system, cause the computing system to:
generating an anchor object, the anchor object having attributes that cause a client application of a content management system to recognize the anchor object as pointing to an external directory reachable by the first client device; the external directory is external to the directory on the first client device that includes the anchor object; and
representing the anchor object as a folder within the directory containing the anchor object on the first client device, the child objects of the anchor object being in a path below the anchor object; , the anchor object is represented as a link placeholder on a file system of the first client device;
synchronizing at least one object on the external directory to the content management system;
A computer readable medium that causes the computer to perform . 12. The computer readable medium of claim 11 ,
The computer-readable medium, when executed by the computing system, causes the computing system to:
recognizing the anchor object by the client application , the anchor object being recognized by the presence of the attribute;
reading the contents of the external directory;
A computer readable medium further comprising instructions for performing. 13. The computer readable medium of claim 12 ,
The computer-readable medium wherein the directory storing the anchor object is a synchronization directory that the client application synchronizes to the content management system. 14. The computer readable medium of claim 13 ,
The computer-readable medium, when executed by the computing system, causes the computing system to:
causing a representation of the synchronization directory to be stored in a local tree structure representing a file system structure of objects in the synchronization directory, including the anchor object, the anchor object being the anchor object; The computer-readable medium is represented in the local tree structure as the folder having a flag as part of the attributes to indicate the folder. 15. The computer readable medium of claim 14 ,
The computer-readable medium, when executed by the computing system, causes the computing system to:
reading the attribute of the anchor object;
creating an in-memory map based on the attributes to convert a universally unique device identifier (UUID) of the external directory to a content management system path within the local tree structure ;
A computer readable medium further comprising instructions for performing. 16. The computer readable medium of claim 15 ,
A computer-readable medium, wherein the attributes serve as a source of truth about an identity of an external object and a location of the external object. A system,
at least one storage configured to store instructions;
at least one processor, the at least one processor executing the instructions to cause the at least one processor to:
receiving a communication from a first client device for synchronizing an anchor object by a content management system, the anchor object providing the content management system with an external directory reachable by the first client device; an object having attributes that cause the anchor object to be recognized as pointing to an object, the external directory being external to a directory on the first client device that includes the anchor object;
representing the anchor object as a folder within the directory containing the anchor object on a web server of the content management system, wherein child objects of the anchor object are within a path below the anchor object; What is expressed as something,
synchronizing the anchor object on the first client device, the anchor object being represented as a link placeholder on a file system of the first client device;
A system configured to cause 18. The system according to claim 17 ,
The system wherein the anchor object and the child object are browsable and viewable on the web server of the content management system. 18. The system according to claim 17 ,
The instructions further cause the at least one processor to:
synchronizing the anchor object to a second client device, the anchor object being represented as a second link placeholder on a second file system of the second client device, and the external directory The client device of the system is not reachable. 20. The system of claim 19 ,
the link placeholder, when selected at the second client device, is configured to cause the second client device to direct a second web browser to the web server of the content management system; system.

Images