REGENERATED CONTAINER FILE STORING

• US 20180004766A1
• Filed: 01/29/2015
• Published: 01/04/2018
• Est. Priority Date: 01/29/2015
• Status: Active Grant

• Current Assignee: Longsand Limited (Open Text Corporation)
• Original Assignee: Longsand Limited (Open Text Corporation)
• Inventors: Darling, Randy S.
• Granted Patent: US 11,314,690 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 16/13 File access structures, e.g. distributed indices arrangements of input from, or output to, record carriers G06F3/06
• CPC Class Codes: G06F 16/137 Hash-based content-based indexing of textual data G06F16/31
• CPC Class Codes: G06F 16/164 File meta data generation
• CPC Class Codes: G06F 16/183 Provision of network file services by network file servers, e.g. by using NFS, CIFS network file access protocols H04L67/1097

Abstract

A regenerated container file is detected, and a file in the regenerated container file is determined that is different from any file in an existing container file related to the regenerated container file. To store the regenerated container file, the different file is sent to the data storage for storing.

Claims

1. A container file management system comprising:

a processor to;

detect creation of a new container file;

determine whether the new container file is a regenerated container file of an existing container file stored in a data storage, wherein the regenerated container file does not reference the existing container file when it is initially created;

if the new container file is the regenerated container file, determine if a file different from any file in the existing container file is contained in the regenerated container file; and

send the different file to the data storage without sending any files in the regenerated container file that are the same as files in the existing container file, wherein the data storage stores the regenerated container file.

2. The container file management system of claim 1, wherein the new container file is not created from an existing container file.

3. The container file management system of claim 1, wherein to determine whether the new container file is a regenerated container file of an existing container file, the processor is to compare metadata of the new container file to metadata of container files stored in the data storage.

4. The container file management system of claim 3, wherein the metadata of the new container file comprises at least one of container file name and container file size.

5. The container file management system of claim 1, wherein the processor is to:

compare a manifest of the regenerated container file to a manifest of the existing container file; and

determine if any differences exist between files in the regenerated container file and files in the existing container file based on the comparison.

6. The container file management system of claim 5, wherein the processor is to:

if none of the files in the regenerated container file are different from the files in the existing container file, as determined based on the comparison, or if a file from the existing container file is not included in the regenerated container file and the remaining files in the regenerated container file are the same as files in the existing container file,

send the manifest of the regenerated container file to the data storage for storage without sending any of the files in the regenerated container file to the data storage.

7. The container file management system of claim 6, wherein the data storage stores the manifest for the regenerated container file.

8. The container file management system of claim 5, wherein the manifest of the regenerated container file and the manifest of the existing container file comprise:

file position information of files in a container file, wherein the file position information includes, for each file in the container file, unique file identifier (id), file id offset, file hash, and file length; and

file segment location information identifying location of each file on the data storage, wherein the file segment location information includes, for each file, file hash, segment id, segment offset, and file length.

9. The container file management system of claim 1, wherein the processor sends the different file to the data storage in predetermined segment-sized bytes over a network.

10. The container file management system of claim 1, wherein the data storage comprises object storage, and the data storage stores objects of the regenerated container file as a plurality of segments.

11. A server connectable to a plurality of clients over a network, the server comprising:

a data storage to store files for container files in segments in the data storage, wherein each segment is a predetermined number of bytes;

a processor to;

receive, from a client via the network, a manifest for a regenerated container file, a file for the regenerated container file, and a request to store the file in a new segment for the regenerated container file, wherein the regenerated container file is related to an existing container file, and the file is not included in the existing container file;

identify a new segment in the data storage to store the new file for the regenerated container file;

store the file in the new segment;

update the manifest to indicate the new file is stored in the new segment; and

send the updated manifest to the client via the network.

12. The server of claim 11, wherein the manifest of the regenerated container file comprises:

file position information of files in the regenerated container file, and

file segment location information identifying location of each segment of the regenerated container file in the data storage; and

to update the manifest, the processor includes location of the new file in the file position information, and includes location of the new segment in the file segment information.

13. The server of claim 12, wherein the file position information comprises, for each file in the regenerated container file, unique file identifier (id), file id offset, file hash, and file length, and

the file segment location information comprises, for each file in the regenerated container file, file hash, segment id, segment offset, and file length.

14. A method of updating a container file in a client device, the method comprising:

sending an update request to a server-side container file management system via a network from the client, wherein the update request includes a manifest of a container file, and the server-side container file management system determines if a regenerated container file related to the container file is stored in server data storage based on the manifest, wherein the regenerated container file is not generated from the container file; and

receiving, at the client, from the server-side container file management system, differences between the regenerated container file and the container file and a manifest for the regenerated container file in response to the server-side container file management system determining that the regenerated container file is stored in the server data storage.

15. The method of claim 14, wherein the server-side container file management system determines the differences by comparing the manifests of the container file and the regenerated container file.