Organizing versioning according to permissions

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for storing data according to permissions. In general, one aspect of the subject matter described in this specification can be embodied in methods that include the actions of identifying a version of a data item to be stored; determining permissions associated with the version of the data item; and storing the version of the data item at a storage location that is based on the determined permissions.

BACKGROUND

This specification relates to storing data.

Typical systems allow for the storage of multiple versions of a data item (e.g., versions of a file stored in a backup). In some conventional systems, these versions are stored according to the location of the data item in a hierarchical file system, for example, within the file system hierarchy of a local device or in a backup that mimics the file system hierarchy. Thus, storing a version typically requires storing the entire file system directory path. Conventionally, all versions of the data item have the same permissions as the permissions of the current data item.

SUMMARY

This specification describes technologies relating to storing data according to permissions.

In general, one aspect of the subject matter described in this specification can be embodied in methods that include the actions of identifying a version of a data item to be stored; determining permissions associated with the version of the data item; and storing the version of the data item at a storage location that is based on the determined permissions. Other embodiments of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.

These and other embodiments can each optionally include one or more of the following features. Storing the version of the data item comprises storing the version of the data item within a node of a permissions tree corresponding to the determined permissions. Storing the version further comprises: determining whether there is an existing branch of the permissions tree associated with the determined permission; and if not, generating a new branch of the permissions tree associated with the determined permission. The permissions tree includes one or more nodes, each node associated with specific permissions. The version is stored without regard to the location of the data item with respect to a file system hierarchy. Access to the version of the data item by a user is controlled by the permissions associated with the storage location in which the version of the data item is stored. The version of the data item has a different permissions than a second version of the data item, wherein the second version of the data item is stored at a second storage location that is based on the permissions of the second version of the data item.

In general, one aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving a request from a user for one or more versions of a data item; identifying the one or more versions of the data item; determining the permissions associated with each version of the one or more versions of the data item; and providing access only to those versions of the one or more versions of the data item to which the user has permission. Other embodiments of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.

These and other embodiments can each optionally include one or more of the following features. determining the permissions includes searching a database for the one or more versions of the data item, the database including an ordering of versions for each of a plurality of data items and a location within a permissions tree of each version. The location of each version of the data item is based on the assigned permissions for each respective version of the data item. All identified versions of the one or more versions of the data item are presented, but only those to which the user has permissions are accessible. Only those versions of the one or more versions of the data item to which the user has permission are presented.

Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. A permissions based versioning system allows versions of data items to be stored more compactly in a permissions tree. Thus, there is no need to store an entire file hierarchy associated with the stored versions of the data items. The permissions tree only adds additional nodes when new permissions are generated. Permissions for particular versions can remain fixed over time so that access to versions can be different based on the permissions at the time respective versions are generated.

DETAILED DESCRIPTION

A system can store one or more versions of a data item (e.g., a file) for later retrieval. A data item can be a file (e.g., a document, media file (movie, image, audio)) or other data. Versions of data items are stored according to their permissions at the time of storage. As a result, the original location within the file system is not used. Instead, versions of data items are stored and indexed according to the permissions assigned to that version of the data item at the time of storage. Each version of the data item is stored according to the permissions of that version without changing previously stored versions.

For example, if a first version has permissions allowing User A to read the file, the first version is stored according to the permission “User A Read”. If a second version has different permissions, e.g., User B allowed to read and User A no longer having permissions, the second version is stored according to the permission “User B Read”. User A will not have access to the second version since User A does not have permission for that version of the data item. However, User A will retain access to the first version. In some implementations, when a user requests one or more versions of a data item, the permissions associated with that data item are identified and only those data items to which the user has permissions are presented.

A useful analogy is to a set of permissions buckets where each bucket has particular permissions (e.g., User A Read). Versions of data items are placed in the corresponding buckets that have matching permissions. A new bucket is generated if the permissions of the version to be stored do not have a corresponding bucket. In some implementations, once a version of a data item is placed in a bucket, it is never removed, thus the permissions are fixed for the version of the data item after being placed in a particular bucket.

FIG. 1is an example representation of a permissions based data store100. In particular, the permissions based data store100illustrates that the versions of data items are not stored according to their file system location, but instead according to their respective permissions. A permissions tree is generated in which each node is associated with particular permissions. Different types of permissions are possible including read access, write access, and read-write access. Other types of permissions can be assigned, for example, an execute permission that grants the ability to execute a file (e.g., a script or other executable file type). Permissions can be assigned to specific users (or user accounts) or groups of users. Additionally, a data item can be associated with more than one type of permission and the permissions can be assigned to more than one distinct user. In some implementations, permissions are subtractive such that full permissions are granted to all data items until limited by more restrictive permissions.

Specifically, permissions based data store100shows a root node102and three permissions nodes104,106, and108branching from root node102. Node104is associated with the permission “Fred Read-Write”. Node106is associated with the permission “Fred and Bob Read”. Node108is associated with the permission “Group Read” where a Group could be all users or some specified group of users.

Versions of data items are stored according to the assigned permissions. Thus, for example, Data Item 1.1 refers to version 1 of data item 1. As shown inFIG. 1, Data Item 1 includes versions 1 and 2 as having permission “Fred Read-Write”. However, Data Item 1.3 (version three of data item 1) has permissions “Group Read”. Thus, while Fred alone has access to versions 1 and 2, version 3 is accessible by all users of the group. As another example, Fred alone has access to version 4 of data item 3 (Data Item 3.4) while Fred and Bob have read access to versions 1, 2, 3, and 5 of data item 3. Thus, Bob cannot access version 4 of data item 3, but can access the other versions. While the versions of the data items are shown for clarity as ordered (e.g. by version number or by data item), the versions of the data items may or may not be stored in an ordered form.

FIG. 2is a flow diagram of an example process200for storing a data item version according to permissions assigned to that data item. The process200can be performed, for example, by one or more computing devices (e.g., a computer, mobile device, tablet device, personal data assistant, server, or other device).

A version of a data item to be stored is identified (step202). A version of a data item can be identified in a number of ways. For example, a version can be generated based on a user editing of the data item. In another example, saving a modified data item can result in a new version being stored. In some implementations, versions are generated and stored prior to writing new modifications or saving a new current data item. For example, a current data item can be modified. The unmodified version is stored as a past version while the modification is applied to the current data item. For example, in some implementations, modifications to a data item are intercepted prior to execution and a version is generated prior to the modification taking place.

In some implementations, the current data item is a version that is also stored with the earlier versions of the data item (if any). The current data items and earlier versions may or may not be stored in an ordered form. In some other implementations, the current data item resides only in the file system hierarchy and is not stored with the prior versions (e.g., in the permissions based data store).

A determination is made of the permissions associated with the version of the data item to be stored (step204). In some implementations, the data item is inspected to determine all assigned permissions. The permissions can include different permissions types for one or more users. Thus, the type of permissions for each assigned user is determined. Permissions can be stored as part of the data item, attributes of the data item, or as part of an access control list for the data item or for a group of data items.

The version of the data item is stored within a permissions tree based on the determined permissions (step206). For example, the version of the data item can be associated with a particular node of a permission tree. If the particular permissions of the data item already exist in the permissions tree, then the data item version is stored in a location associated with the corresponding permissions. Additionally, in some implementations, permissions are subtractive such that unless specified otherwise all users have permission. Thus, a compact permissions tree can be formed in which a full group node allows full access to all users. All versions can be stored with this node unless otherwise specified with more limiting permissions (e.g., permissions to a single user).

A new node in the permissions tree can be generated when the determined permissions do not appear already in the permissions tree. For example, if a version of the data item to be stored has permissions “Fred Read” this means only user Fred can read the data item. If the permissions tree only has a node for “full group access” a new node in the permissions tree is generated for “Fred Read”. The version of the data item is then added to the newly generated branch of the permissions tree.

In some implementations, adding a new version to the permissions tree also includes updating a versions database that includes an ordered list of versions for each data item and a respective location in the permissions tree.

FIG. 3is a block diagram of an example permissions based versioning system300. The permissions based versioning system includes a versions database302and a permissions store304. Particular versions can be requested by and/or presented to a user306through a particular user interface308. For example, a user interface308can be a user interface to the file system (e.g., a search utility or application, backup application, or specific versioning interface).

The permissions store304includes the versions stored according to assigned permissions in the permissions tree. The versions database302can include an ordering of versions of each data item and their respective locations within the permissions store304(e.g., a particular permissions node in the permissions tree). Alternatively, in some implementations, the versions database302includes the version of each data item in a different or unordered form that maintains an identification of their respective locations within the permissions store304. Thus, when a request for versions of a particular data item is received, the versions database302can be searched to identify all versions of that data item and their respective locations in the permissions store304. Additionally, since the permissions store is organized by permissions, the locations in the database also identify the permissions of each version.

In some implementations, the versions database302includes metadata associated within each version. The metadata for a particular version can include information on how the particular version was generated, user explanatory text, contextual information, conflict resolution information, and other annotations.

FIG. 4is a flow diagram of an example process400for retrieving a data item. The process400can be performed, for example, by one or more computing devices as described above with respect toFIG. 3.

A request is received from a user for one or more versions of a data item (step402). The request can be received, for example, as part of a search performed in a user interface to the file system. For example, a user working in the current data item can request prior versions of that data item in order to identify particular changes or recover particular content found in an earlier version. In some implementations, the user can input search parameters into a search interface to include one or more versions of data items in the search rather than just the current data items in the file system.

One or more versions of the data item are identified (step404). In some implementations, a database of versions is searched to identify stored versions of the data item. The versions can be indexed in the database by data item in order to identify all versions of the data item. In some implementations, an identifier for the data item is used to identify versions of the data item within the database. For example, each data item can have a unique identifier. Additionally, each version stored can be associated with that unique identifier. Thus, the unique identifier can be used to identify each version of the data item.

The permissions associated with each version of the one or more versions of the data item are determined (step406). Different versions of the same data item can have different permissions. In some implementations, determining permissions for a version includes examining the permissions associated with parent or ancestor items in a hierarchical file system. Each version has an identified location in a permissions store where the version of the data item is stored. Thus, the location also identifies the permissions for each respective version. Different versions of data items can be associated with different permissions.

For example, a first user can grant permission to a second user to read and write to forward versions of the data item. Thus, if versions 1-5 of the data item already exist at the time the second user was granted permission, the second user would still not have access to versions 1-5. However, the second user would have access to versions 6 and on. If after the tenth version, the first user rescinds the permission of the second user, the second user would still maintain access to versions 6-10, but would no longer have access for later versions (versions 11 and on). This is because the versions are stored in the versions store according to permissions and they are not moved when permissions change for later versions. The associated permissions can be shown, for example, as:Data item versions 1-5: No permissions to the second user.Data item versions 6-10: Read and Write permission for second user.Data item versions 11 and on: No permissions to the second user.
However, in some other implementations, versions can be moved as permissions change so that all versions of a data item maintain consistent permissions.

Those versions of the one or more versions of the data item to which the user has permission are presented (step408). For example, the versions can be presented in a list or other visual representation of versions. In some implementations, a list of versions is generated with associated links (e.g., uniform resource locator links) to the corresponding versions of the data item. Alternatively, the versions can be presented as items identifying a path to the location of the respective versions in the permissions tree. The list can include all versions or can include only those versions to which the requesting user has permission. For example, when presenting a list of all of the versions, the links to those in which the user does not have access will not be active. For those that the user does have permission, the user can select the version from the list using the link, which causes the selected version of the data item to be accessed (e.g., a file can be opened by the associated application).

In some implementations, the permissions of the current data item is identified. If the requesting user does not have permission to the current version of the data item, than no versions of the data item are presented to the user. Thus, access to any versions of a data item can be predicated on access to the current data item.

FIG. 5illustrates an example architecture of a system500. The system architecture500is capable of performing operations for storing versions of data items based on permissions. The architecture500includes one or more processors502(e.g., IBM PowerPC, Intel Pentium 4, etc.), one or more display devices804(e.g., CRT, LCD), graphics processing units506(e.g., NVIDIA GeForce, etc.), a network interface508(e.g., Ethernet, FireWire, USB, etc.), input devices510(e.g., keyboard, mouse, etc.), and one or more computer-readable mediums512. These components exchange communications and data using one or more buses514(e.g., EISA, PCI, PCI Express, etc.).

The term “computer-readable medium” refers to any medium that participates in providing instructions to a processor502for execution. The computer-readable medium512further includes an operating system516(e.g., Mac OS®, Windows®, Linux, etc.), a network communication module518, a permissions versioning manager520, and other applications524.

The operating system516can be multi-user, multiprocessing, multitasking, multithreading, real-time and the like. The operating system516performs basic tasks, including but not limited to: recognizing input from input devices510; sending output to display devices504; keeping track of files and directories on computer-readable mediums512(e.g., memory or a storage device); controlling peripheral devices (e.g., disk drives, printers, etc.); and managing traffic on the one or more buses514. The network communications module518includes various components for establishing and maintaining network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, etc.).

The permissions versioning manager520provides various software components for performing the various functions for storing versions of data items based on permissions, as described with respect toFIGS. 1-4.