Regenerated container file storing

1. A container file management system comprising:

a processor to:

detect a creation of a new container file;

determine whether the new container file is a regenerated container file of an existing container file, wherein the regenerated container file is created from an empty container file and not created from the existing container file;

in response to a determination that the new container file is the regenerated container file of the existing container file, create, for the regenerated container file, a manifest that includes file position information identifying positions of regenerated files located in the regenerated container file;

compare the manifest for the regenerated container file to a manifest for the existing container file stored in a data storage to determine a new file of the regenerated container file that is different from existing files of the existing container file;

send a request to the data storage to store the new file of the regenerated container file in a new segment in the data storage that is different from first segments in the data storage that store the existing files of the existing container file; and

in response to receiving a location of the new segment in the data storage where the new file is stored, update the manifest for the regenerated container file to include segment location information including the location of the new segment in the data storage where the new file is stored.

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

3. The container file management system of claim 2 , wherein the metadata of the new container file comprises a container file name and a container file size.

4. The container file management system of claim 1 , wherein the manifest for the existing container file includes file position information identifying positions of the existing files located in the existing container file and segment location information identifying locations of the first segments in the data storage where the existing files are stored.

5. The container file management system of claim 4 , wherein the file position information identifying the positions of the existing files located in the existing container file includes, for each of the existing files, a unique file identifier (id), a file id offset, a file hash, and a file length.

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

send the updated manifest for the regenerated container file to the data storage for storage.

7. The container file management system of claim 1 , wherein the processor is to send the new file of the regenerated container file to the data storage in predetermined segment-sized bytes over a network.

8. The container file management system of claim 1 , wherein the data storage comprises object storage, and the object storage stores the new file of the regenerated container file.

9. 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 has a predetermined number of bytes; and

a processor to:

receive, from one client of the plurality of clients via the network, a manifest for a regenerated container file, wherein the manifest for the regenerated container file includes metadata identifying regenerated files in the regenerated container file and positions of the regenerated files in the regenerated container file, wherein the regenerated container file is related to an existing container file stored in the data storage and wherein the regenerated container file is created from an empty container file and not from the existing container file;

receive, from the client, a new file of the regenerated container file that is different from existing files of the existing container file;

request the data storage to store the new file of the regenerated container file in a new segment in the data storage that is different from first segments in the data storage that store the existing files of the existing container file;

in response to receiving a location of the new segment in the data storage where the new file is stored, update the manifest for the regenerated container file to include segment location information including the location of the new segment in the data storage where the new file is stored; and

send the updated manifest for the regenerated container file to the client via the network.

10. The server of claim 9 , wherein the manifest for the existing container file comprises:

file segment location information identifying a location of each of the first segments in the data storage where the existing files are stored.

11. The server of claim 9 , wherein the manifest for the regenerated container file further comprises, for each of the regenerated files in the regenerated container file, a unique file identifier (id), a file id offset, a file hash, and a file length.

12. A method comprising:

detecting a creation of a new container file;

determining that the new container file is a regenerated container file of an existing container file, wherein the regenerated container file is created from an empty container file and not from the existing container file;

in response to the determination that the new container file is the regenerated container file of the existing container file, creating, for the regenerated container file, a manifest that includes file position information identifying positions of regenerated files in the regenerated container file;

comparing the manifest for the regenerated container file to a manifest for the existing container file to determine a new file of the regenerated container file that is different from existing files of the existing container file;

sending a request to a data storage to store the new file of the regenerated container file in a new segment in the data storage that is different from first segments in the data storage that store the existing files of the existing container file; and

in response to receiving a location of the new segment in the data storage where the new file is stored, updating the manifest for the regenerated container file to include segment location information including the location of the new segment in the data storage where the new file is stored.

13. The method of claim 12 , wherein the manifest for the regenerated container file further comprises, for each of the regenerated files in the regenerated container file, a unique file identifier (id), a file id offset, a file hash, and a file length.

14. The method of claim 12 , wherein the manifest for the existing container file comprises storage information including, for each of the existing files of the existing container file stored in the data storage, a segment id, a segment offset, and a file length.

15. The server of claim 9 , wherein the manifest for the existing container file includes, for each of the existing files, a segment id, a segment offset, and a file length.

16. The method of claim 12 , wherein determining that the new container file is the regenerated container file of the existing container file comprises:

comparing metadata of the new container file to metadata of all container files, including the existing container file, wherein the metadata of the new container file comprises a container file name and a container file size.