Patent Application
20170075920
The notion of file sharing and synchronization is facing significant challenges to manage business data across a variety of end-user devices and Bring Your Own Device (BYOD) features. A general embodiment of file sharing and synchronization for business data is the case where end users (typically Small and Medium Enterprises (SMEs)) have the opportunity of choosing their own preferred file storage system as part of their own hardware located at their own premises. This embodiment imparts end users the ability to create their own private cloud for internal and external use. This embodiment further imparts end users the ability to leverage upon the use of an IT reseller's file storage and/or an IT service provider's private cloud storage in conjunction to create highly scalable hybrid cloud storage to store their data.
A second general embodiment of file sharing and synchronization for business data is the case where the same user accesses and edits the same file from multiple locations using different devices (e.g. Tablet, Mac, PC, Smartphone et al.). The type of devices are unrestricted as in the knowledge of existing state-of-the-art communication, information processing and display technologies.
A third general embodiment of file sharing and synchronization for business data is the case where a group of users using different end devices located at multiple geographies access and edit the same file simultaneously. The scope of multiple geographies is unrestricted by the coverage area (e.g. suburb, city, multiple cities in the same country, multiple cities in different countries, intercontinental locations et al.)
The first major challenge in realizing these general embodiments is to achieve scalability in file synchronization across multiple end user devices. As the type and volume of new end user devices increases with deeper market proliferation, realizing seamless instantaneous file synchronization for file access/edit purposes will be difficult.
The second major challenge in realizing these general embodiments is to achieve large-sized file sharing between multiple end users. For business data, this is particularly of relevance as personnel from multiple business units located at different geographies might want to review and edit a set of common documentation libraries simultaneously. In that case, large file sharing with correct change versions becomes difficult.
There is thus a need for a system and methods that can enable scalability in file synchronization across multiple end user devices and can further enable large file sharing between multiple end users. A comprehensive due diligence on state-of-the-art file sharing and synchronization products available in prior art distinctly shows the limited features in current solutions and techniques for solving the scalability and large file sharing problems.
From the different file sharing and synchronization types and methods studied in the prior art, the limitation of methods for precise file system event detection for user operations can be inferred. To achieve scalability in file synchronization across an increasing number of multiple end user devices, capability of detecting precise file system events and associating them with corresponding user operation types (e.g. file create, file rename, file delete et al.) is required. Further, methods that capture exact file system events for large-sized file sharing (e.g. file copy) between multiple end users and resolve conflicts in simultaneous file change requests are limited in the prior art.
This invention develops the capability of identifying a single file system event from an automatically generated sequence of multiple file system events upon a single user operation.
On the path to developing this capability, this invention develops methods that can uniquely detect the exact file system event generated by a single user operation (e.g. file create, file rename et al).
This invention further develops methods that overcome the challenge of masking extraneous file system events generated during a single user operation.
This invention further develops methods that detect file system events for new folder, sub-folder and file creation during directory sharing for subsequent replication.
This invention further develops methods that overcome the challenge of large file copy detection. An embodiment of this invention is bridging the notion of inability to access any file during an ongoing file copy operation. The normative error that is obtained in this attempt is an access sharing violation that is used as an indicative file system event of simultaneous file access and/or copy.
This invention further develops methods that detect file download and consequential user operations based on file instance differences between a client and server. The technical challenge of overcoming simultaneous file changes by multiple end users is embodied in this invention as a Request Queue Framework.
This invention further develops methods that resolve conflicts in simultaneous file change requests by multiple end users.
The foregoing summary, as well as the following description of the invention, is better understood when read with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary embodiments of various aspects of the invention. The invention is however not limited to the specific disclosed methods and instrumentalities.
The subject matter of this present invention is described with specificity to highlight the resolution of technical challenges faced in realizing general embodiments of file sharing and synchronization for business data. The description itself is not intended to limit the scope of this patent. The inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies.
As shown in
An end user creates a file X using a Tablet 310 that communicates directly with a Server 410 via a private or public network The file X can be of any type embodying business data (e.g. Microsoft Excel, Microsoft Word, Microsoft PowerPoint et al.). The Tablet 310 can be of any vendor model and the Server 410 can be of any server type (e.g. Windows Server 2008 R2, Oracle Database 12C et al.). Once the user has created a first version of the file X and uploaded onto the Server 410, he edits this file X using his Tablet 310. The changed version 361 of File X, Xi, is communicated to Server 410 and stored there. The user then moves to a different geographical location (e.g. a different section of the same office, a different suburb, a different town, a different country and/or a different intercontinental location) and uses a Notebook 320 to communicate with Server 410 for accessing X1. Upon accessing X1, the user edits this file again and the changed version 362 of File X1, X2, is communicated to Server 410 and stored there. The user then keeps moving to consecutive other geographical locations and repeats the prior mentioned steps using a PC 330, PDA 340 and Mac 350. The version of the same file X2 keeps on changing accordingly through versions 363, 364 and 365. In each location, using a different device, the end user is successfully able to access his changed file correctly, edit it and upload it to Server 410. This step is independent of the number of devices in question as well as the type of device used.
As shown in
An end user creates a file X using a Tablet 10 that communicates directly with a Server 70 via a private or public network The file X can be of any type embodying business data (e.g. Microsoft Excel, Microsoft Word, Microsoft PowerPoint et al.). The Tablet 10 can be of any vendor model and the Server 70 can be of any server type (e.g. Windows Server 2008 R2, Oracle Database 12C et al.). Once the user has created a first version of the file X and uploaded onto the Server 70, he edits this file X using his Tablet 10. The changed version 61 of File X, X1, is communicated to Server 70 and stored there. At the same time, end users located at different geographies try and access the same file Xi using different devices—a Notebook 20, a PC 30, a PDA 40 and a Mac 50. Each end user accesses File X1 and edit it simultaneously creating multiple versions 62, 63, 64 and 65. The changed versions are stored in the Server 70 and all the changed content created through versions 62, 63, 64 and 65 of X1 are instantly visible and accessible to each end user using different devices—a Tablet 10, a Notebook 20, a PC 30, a PDA 40 and a Mac 50. The Server 70 stores the final changed version of X1 after the last end user has finished editing it. This invention enables conflict resolution when the same file name is created by multiple users. This invention further enables simultaneous edit of a single file by multiple end users located at different geographies using different devices by working around the file share access violation problem.
As shown in
A group of end users create a file X using a set of Tablets 110 that communicates directly with a Server 170 via a private or public network. The file X can be of any type embodying business data (e.g. Microsoft Excel, Microsoft Word, Microsoft PowerPoint et al.). The Tablets 110 can be of any vendor model and the Server 170 can be of any server type (e.g. Windows Server 2008 R2, Oracle Database 12C et al.). Once the user group has created a first version of the file X and uploaded onto the Server 170, they edit this file X using Tablets 110. The changed version 161 of File X, X1, is communicated to Server 170 and stored there. By default File X is always shared within Business Unit 1 so that all users under this group are able to access the same files and work as a team. This invention facilitates an extended share mechanism so that Business Unit 1 can share their workspace with other groups Business Unit 2, Business Unit 3, Business Unit 4 and Business Unit 5. Business 1 can further configure restrictive access while sharing their workspace with other groups to allow them ‘read only’, ‘read write’ or ‘full control’ permissions. This ensures safety of business data and prevents accidental data deletion by other groups. As shown in
As shown in
Virtual Hard Disk (VHD) 1 is an embodiment of software emulation of a physical hard disk drive. An embodiment of a VHD on a host machine allows software emulation of multiple operating systems and physical hardware. This embodiment enables easy communication with remote servers, data backup, recovery and multi-user isolation. File system events are automatically generated during a particular user operation instruction on the VHD (e.g. file create, file rename et al.). The VHD has a unidirectional out-link with Event Catcher 2 and unidirectional out-link with Open File Identifier 8.
Event Catcher 2 is the unit where the automatically generated file system events are collected and sorted for the large number of incoming events. Event Catcher has a unidirectional in-link with VHD 1 and a unidirectional out-link with Event Filter 3. Event Filter 3 is the unit where the sorted file system events are filtered for hidden and temporary files. This section further implements a local software-based queue, ClientReqAcceptor Q1, for queuing sequenced filtered file system events and providing necessary buffer time to execute event processing to completion. This ensures that operations take place in the sequence they occur and no event is missed due to a delay in execution. The output of ClientReqAcceptor Q1 has a unidirectional out-link with Event Processor 4.
Event Processor 4 is the unit where the methods described within the scope of this invention are implemented on the client side. The filtered file system events that are placed on ClientReqAcceptor Q1 are identified, matched and processed corresponding to the user operation that was performed on VHD 1. Event Processor has a unidirectional out-link with File Uploader 6, a bidirectional in-out-link with Client Strata 5 and a unidirectional in-link with Open File DB 10.
Client Strata 5 is a database on the File Client side where information related to client side user operations are stored. Client Strata 5 can have any embodiment within current state-of-the-art database design and implementation existing in prior art. In this invention, it is implemented using SQL Lite. Client Strata 5 has a bidirectional in-out-link with Strata Comparator 11, a bidirectional in-out-link with Open File Processor 7 and a bidirectional in-out-link with Event Processor 4.
File Uploader 6 is the unit where events related to file uploading are processed corresponding to the set of user operations (e.g. file create, file rename, file edit et al.). This can be mapped from the versions 61, 62, 63, 64, 65 of
Open File Processor 7, Open File Identifier 8, XML Parser 9 and Open File DB 10 are relevant only to “file open” events and is implemented in this invention using OpenedFilesView v1.52, a third-party freeware available in the open source domain.
Open File Identifier 8 is the unit that processes a file open event once a corresponding user operation on VHD 1 is executed. This unit keeps on listening to and waits for a “file open” event from the VHD. Upon processing the “file open” event, this unit converts the file system event to a XML string. Open File Identifier 8 has a unidirectional in-link with VHD 1 and a unidirectional out-link with XML Parser 9.
XML Parser 9 is the unit that parses the XML string generated from Open File Identifier 8. XML Parser 9 has a unidirectional in-link with Open File Identifier 8 and a unidirectional out-link with Open File DB 10.
Open File DB 10 is a database on the File Client side where the parsed XML data associated with a “file open” event is stored. Open File DB 10 can have any embodiment within current state-of-the-art database design and implementation existing in prior art. In this invention, it is implemented using SQLite. SQLite is a software library that implements a self-contained, server-less and transactional SQL database engine that can easily work with on limited computing resources. Open File DB 10 has a unidirectional in-link with XML Parser 9 and a unidirectional out-link with Open File Processor 7.
Open File Processor 7 is the unit that generates threads per processed “file open” event sourced in XML format from Open File DB 10. Open File Processor 7 constantly listens from Open File DB 10 for the occurrence of a “file open” event and upon detection, generates a corresponding thread that remains associated with that file till its lifetime (e.g. till the file is closed and a “file closed” event is generated by the corresponding user operation on VHD 1). This is then communicated with File Uploader 6 for linking with the Listener on the File Server side. Open File Processor 7 has a unidirectional in-link with Open File DB 10, a unidirectional out-link with File Uploader 6 and a bidirectional in-out-link with Client Strata 5.
Strata Comparator 11 is the unit where current records for client strata are compared. Based on the strata comparison that takes place at State Comparator 11, a decision can be made about the state of the client being in sync or out-of-sync. If all the files/folders are out of sync, Strata Comparator 11 may take a decision of downloading missing files or uploading newly created files to the server. Strata Comparator 11 is also responsible for ensuring that Client Strata 5 is sync-ed with the latest changes. The final decision flow is passed to File Operation Processor 13. Strata Comparator 11 has a bidirectional in-out-link with Client Strata 5, a unidirectional out-link with File Operation Processor 13 and a unidirectional in-link with Strata Downloader 12.
Strata Downloader 12 is the unit that retrieves records for user operation generated file system events from the File Server side. Strata Downloader has a unidirectional in-link with Strata Encoder 21 and a unidirectional out-link with Strata Downloader 12.
File Operation Processor 13 is the unit that processes and maps file system event data back to corresponding user operations. It receives corresponding records for user operation generated file system events from Strata Comparator 11 to match the user operations while performing the reverse mapping. Based on the information provided by Strata Comparator 11, File Operation Processor 13 can request File Encoder 22 to download a file that is not present or modified on VHD 1. File Operation Processor 13 has a unidirectional out-link with VHD 1, a unidirectional in-link with File Encoder 22 and a unidirectional in-link with Strata Comparator 11.
Listener 14 is the unit that listens for an event generated by placing a request on FileUploadQueue Q2 of File Uploader 6. The main function of this unit is to listen and clear the FileUploadQueue as soon as a request is placed on it by File Uploader 6. Listener 14 has a unidirectional in-link with File Uploader 6 through FileUploadQueue Q2 and a unidirectional out-link with Message Decoder 15.
Message Decoder 15 is the unit that decodes the processed file system events of the corresponding user operations involving the server side. Message Decoder 15 has a unidirectional in-link with Listener 14 and a unidirectional out-link with Operation Processor 16.
Operation Processor 16 is the unit where the methods described within the scope of this invention are implemented on the server side. The decoded file system events of the corresponding user operations link with Server Strata 17 and the files pushed into a Bucket 18. Operation Processor has a unidirectional in-link from Message Decoder 15, a bidirectional in-out-link with Server Strata 17 and a bidirectional in-out-link with Bucket 18.
Server Strata 17 is a database on the File Server side where information related to server side user operations are stored. Server Strata 17 can have any embodiment within current state-of-the-art database design and implementation existing in prior art. In this invention, it is implemented using SQL Lite. Server Strata 17 has a bidirectional in-out-link with Operation Processor 16, a unidirectional out-link with Strata Puller 19 and a unidirectional out-link with File Puller 20.
Bucket 18 is the unit where files are stored, including large files that are shared and synchronized between multiple end users as shown in embodiments of
Strata Puller 19 is the unit that retrieves the file system event records from Server Strata 17. Strata Puller 19 is a separate entity that is dedicated to extract file records from Server Strata 17 and provide those records to Strata Encoder 21 to communicate with client software. Strata Puller 19 has a unidirectional in-link with Server Strata 17 and a unidirectional out-link with Strata Encoder 21.
File Puller 20 is the unit that retrieves the file system events from Server Strata and the corresponding files from Bucket 18. File Puller 20 has a unidirectional in-link with Server Strata 17, a unidirectional in-link with Bucket 18 and a unidirectional out-link with File Encoder 22.
Strata Encoder 21 is the unit that encodes the file system event records retrieved from Strata Puller 19 to create corresponding server strata records. Strata Encoder has a unidirectional in-link with Strata Puller 19 and a unidirectional out-link with Strata Downloader 12.
File Encoder 22 is the unit that processes files for download after corresponding strata record matching and file system event record retrieval has been performed correctly. These processed files are then sent to File Operation Processor 13 for mapping back to user operations on VHD 1. File Encoder 22 has a unidirectional in-link with File Puller 20 and a bidirectional in-out-link with File Operation Processor 13.
As shown in
The method of a file system event profiler in accordance with this invention is implemented in Event Catcher 2, Event Filter 3, Event Processor 4 and File Uploader 6 illustrated in
As shown in
Event Set E={U(ek), {H}, {T}} comprises of individual file system events ek, Hidden Files {H} and Temporary Files {T}.
In Event Filter 3 (vide
In Event Processor 4 (vide
Depending on the file/directory identification, file and directory events are processed EP8, EP9 in Event Processor 4 (vide
There is a separate process sequence P6 that enables conflict resolution in file content change EP10. This occurs in Event Processor 4 (vide
After the set of process sequences are executed, the user operation is processed correctly EP11 involving the corresponding file system events. Upon success of the microcode execution, the output state variable returns −1 (in case of failure) or 0 (in case of success). This drives the state of the file system event to S2.
As shown in
The method of the file download process and associated server side processing in accordance with this invention is implemented in Server Strata 17, Bucket 18, Strata Puller 19, File Puller 20, Strata Encoder 21, File Encoder 22, Strata Downloader 12 and File Operation Processor 13 as illustrated in
The File Server state initially So is that of Listening for a processed file system event from the Reduced Event Set Ej as described in Section 1.4 of this invention. The Listener 14 (vide
The initial state SSP1 is a null state S0 that resides in listening mode. The input state variables to this state are JSON request records JRR1={U(jrrm)} that comprise client side request identifiers from corresponding user operations generated on VHD 1 (vide
The requests are sent to Strata Encoder 21 that pulls the current strata entries from Server Strata 17 corresponding to the Bucket ID Bk through Strata Puller 19. After the successful communication of the requests, process sequence P2 is executed DL12.
Through the process sequence P2, the input state variable set of the server strata records SSRj={U(ssrm)} is executed DL13 and the strata is sent to Strata Downloader 12 and on to Strata Comparator 11. During execution of operation OP1, the server strata records SSRj are compared with client strata extracted from Client Strata 5 by Strata Comparator 11. Based on the outcome of this comparison, a decision is sent to File Operation Processor 13 (e.g. File Download) that executes DL15 of process sequence P4. The File Download request, following the execution of P4, is sent to File Encoder 22 that extracts an appropriate File ID Fk through File Puller 20. Upon the successful extraction of the file associated with File ID Fk, data is transmitted back to File Operation Processor 13. The File Operation Processor undertakes necessary checks (execution DL16 of process sequence P5) and performs conflict resolution in file content change (execution DL17 of process sequence P6) on VHD 1 before proceeding to store files on VHD 1. The output state variables are File ID Fk & Server Strata Records SSRj={U(ssrm)}. This drives the state of the file system event to S1.
As shown in
For instruction DL14 (vide
Operation OP1, acting on Client's Request Identifier SSP2 generates two further input state variables: a) Server Strata Records SSRj={U(ssrm)}; b) Bucket ID Bk & File ID Fk & Server Strata Records SSRj={U(ssrm)}.
For the input state variables as Server Strata Records SSRj={U(ssrm)} only, Process Sequence P1 executes to extract client specific strata SSP3 that is sent SSP5 to the client by executing Process Sequence P3. After this is executed the second state S1 is reached that again drives to the listening mode, waiting for another client request for identifiers of corresponding user operations. State S1 degenerates to the initial null state S0 after a set timeout window.
For the input state variables as Bucket ID Bk & File ID Fk & Server Strata Records SSRj={U(ssrm)}, Process Sequence P2 executes to update SSP4 Server Strata 17 and Bucket 18 (vide
The embodiment of the method of handling a file create event associated with the client side is a Function F1C that comprises a sequence of method steps as shown in
Function F1C operates on Reduced Event Sets Ej={U(em)}, that comprises individual file system events em, in Event Processor 4 of the File Client Side (vide F1C({U(em)})={U(en)}, where 0<n≦m.
The embodiment of this Communicating Sequential Process-generated further Reduced Event Set Ei is illustrated in
Step 1 of the method MC1 is to determine whether the file exists on the VHD 1 (vide
Step 2 of the method MC2 is to determine whether the file path is present in client strata. Upon a No, the flow passes on to MC3. Upon a Yes, the User Operation is ignored, as the Server provides the instance of the file path. Step 2 is executed on Client Strata 5 (vide
Step 3 of the method MC3 is to determine whether the file is present in the Open Files vector of OpenedFilesView v1.52. Upon a No, the flow passes on to MC4. Upon a Yes, the User Operation is ignored, as the file is handled by OpenedFilesView v1.52. Step 3 is executed on Open File Processor 7 (vide
Step 4 of the method MC4 is to try and open the file and extract a hash associated with the file. Step 4 is executed on Open File Processor 7 (vide
Step 5 of the method MC5 tests the success of the file open and associated hash extraction. Upon a Yes, the flow passes on to MC6. Upon a No, the flow passes on to MC9. Step 5 is executed on Open File Processor 7 (vide
Step 6 of the method MC6 follows the success of opening a file and extracting the hash associated with the file. This step continues on till the file copy is complete. Upon file copy completion, the flow passes on to MC7. Step 6 is executed on Event Processor 4 (vide
Step 7 of the method MC7 updates the local client strata by adding a new record entry for the created file. Upon this completion, the flow passes on to MC8. Step 7 is executed on Client Strata 5 (vide
Step 8 of the method MC8 puts the “file create” request on FileUploadQueue Q2 (refer
Step 9 of the method MC9 determines if there is an access violation error if the file open and hash extraction is unsuccessful. If there is no access violation error, the file is handled through appropriate error handling mechanisms. If there is access violation error, the flow retraces back to MC4, where repeated attempts at trying and opening the file are made along with the corresponding hash extractions. Step 9 is executed on Open File Processor 7 (vide
The embodiment of the method of handling a file create event associated with the server side is a Function F1S that comprises a sequence of method steps as shown in
Step 1 of the method MS1 is retrieving the file from the client which is stored on a temporary folder. Upon successful retrieval of the file, the flow passes on to MS2. Step 1 is executed on Listener 14 (vide
Step 2 of the method MS2 is extracting the file size, hash and file modified time from the retrieved file. Upon successful extraction of the relevant file parameters, the flow passes on to MS3. Step 2 is executed on Message Decoder 15 (vide
Step 3 of the method MS3 determines whether the file is present on the server. Upon a Yes, the flow passes on to MS6. Upon a No, the flow passes on to MS4. Step 3 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 4 of the method MS4 determines if the extracted hash value from the file parameters is zero upon confirmation of the file's presence on the server. Upon a No, the “File Create” User Operation is ignored as the already created file is currently being modified. Upon a Yes, the flow passes on to MS5. Step 4 is executed on Operation Processor 16 (vide
Step 5 of the method MS5 removes the file path entry upon the determination that the extracted has value from the parameters is zero. The hash value is updated at this step. Upon the hash value update, the flow passes on to MS6. Step 5 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 6 of the method MS6 fetches the corresponding bucket object and stores the new created file on the server. Upon successful storage of the new created file on the server, the flow passes on to MS7. Step 6 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 7 of the method MS7 updates the server strata by adding a new row and fetching the stored file identifier. Upon successful server strata update, the flow passes on to MS8. Step 7 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 8 of the method MS8 deletes temporary files. Upon successful temporary file deletion, the flow passes on to MS9. Step 8 is executed on Operation Processor 16 (vide
Step 9 of the method MS9 checks the file's presence on FileUploadQueue Q2 (vide
The embodiment of the method of handling a file size change event associated with the client side is a Function F2C that comprises a sequence of method steps as shown in
Step 1 of the method MC101 determines if the file is present on the client Virtual Hard Drive VHD 1 (vide
Step 2 of the method MC102 determines if the file is present in the Open File database of OpenedFilesView v1.52 upon confirmation that the file is present on VHD 1 (vide
Step 3 of the method MC103 compares the equality of the hash values of the files. Upon a Yes, the User Operation is ignored. Upon a No, the flow passes on to MC104. Step 3 is executed on Open File Processor 7 (vide
Step 4 of the method MC104 updates the client strata. Upon successful and correct update of the client strata, the flow passes on to MC105. Step 4 is executed on Client Strata 5 (vide
Step 5 of the method MC105 changes the file hash value. Upon changing the hash value correctly, the flow passes on to MC106. Step 5 is executed on Client Strata 5 (vide
Step 6 of the method MC106 inserts a ‘file modify’ request on FileUploadQueue Q2 (refer
The embodiment of the method of handling a file modify event associated with the server side is a Function F2S that comprises a sequence of method steps as shown in
Step 1 of the method MS101 retrieves the file name, file size and the local copy of the file. Upon the successful retrieval of the file parameters, the flow passes on to MS102. Step 1 is executed on Bucket 18 (vide
Step 2 of the method MS102 determines if the retrieved file is present on the server strata upon successful retrieval of the file parameters. Upon a No, Function F1S is invoked and the corresponding method steps executed. Upon a Yes, the flow passes on to MS103. Step 2 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 3 of the method MS103 determines if the hash value of the retrieved file is zero. Upon a Yes, the flow passes on to MS104. Upon a No, the flow passes on to MS106. Step 3 is executed on Operation Processor 16 (vide
Step 4 of the method MS104 removes the entry from server strata upon determining that the hash value of the retrieved file is zero. Upon deletion, the flow passes on to MS105. Step 4 is executed on Server Strata 17 (vide
Step 5 of the method MS105 is an exact replica of the method of handling a file create event on the server side in accordance with this invention. Function F1S is invoked and the corresponding method steps executed.
Step 6 of the method MS106 determines if the new hash value of the file is the same as the old one upon confirmation that the retrieved hash value is not zero. Upon a Yes, this User Operation is ignored. Upon a No, the flow passes on to MS107. Step 6 is executed on Operation Processor 16 (vide
Step 7 of the method MS107 updates the hash value of the new file. Upon successful and correct update, the flow passes on to MS108. Step 7 is executed on Server Strata 17 (vide
Step 8 of the method MS108 retrieves the file identifier from the server strata. Upon successful and correct retrieval, the flow passes on to MS109. Step 8 is executed on Server Strata 17 (vide
Step 9 of the method MS109 deletes the file with the corresponding identifier from the bucket. Upon successful deletion, the flow passes on to MS110. Step 9 is executed on Bucket 18 (vide
Step 10 of the method MS110 adds the modified file with the corresponding identifier to the bucket. Upon successful insertion, the flow passes on to MS111. Step 10 is executed on Bucket 18 (vide
Step 11 of the method MS111 deletes all the temporary files. Upon successful deletion, the flow ends from this step. Step 11 is executed on Operation Processor 16 (vide
The embodiment of the method of handling a file rename event associated with the client side is a Function F3C that comprises a sequence of method steps as shown in
Step 1 of the method MC201 determines whether the old file exists in the local client strata. Upon a Yes, the flow passes on to MC202. Upon a No, the flow passes on to MC205. Step 1 is executed on Event Processor 4 and Client Strata 5 (vide
Step 2 of the method MC202 determines if the new file name is present in the local client strata upon confirmation that the old file exists in the local client strata. Upon a Yes, the User Operation is exited due to file open and download conflict and handled accordingly. Upon a No, the flow passes on to MC203. Step 2 is executed on Event Processor 4 and Client Strata 5 (vide
Step 3 of the method MC203 effects a change in the client strata by changing the file name and file path. Upon successful and correct change of the file name and file path, the flow passes on to MC204. Step 3 is executed on Event Processor 4 and Client Strata 5 (vide
Step 4 of the method MC204 inserts a ‘File Rename’ on the ClientReqAcceptor Q1 (vide
Step 5 of the method MC205 updates local client strata with new file name entry under confirmation that the old file does not reside in local client strata. Upon successful and correct update, the flow passes on to MC206. Step 5 is executed on File Uploader 6 (vide
Step 6 of the method MC206 inserts a ‘File Create’ on the FileUploadQueue Q2 (vide
The embodiment of the method of handling a file rename event associated with the server side is a Function F3S that comprises a sequence of method steps as shown in
Step 1 of the method MS201 retrieves the file from the client and extracts file size and hash value from the file parameters. Upon successful file retrieval and relevant file parameter extraction, the flow passes on to MS202. Step 1 is executed on Listener 14 and Message Decoder 15 (vide
Step 2 of the method MS202 stores the retrieved file and the relevant file parameters in a temporary directory on the server. Upon successful execution of this step, the flow passes on to MS203. Step 2 is executed on Operation Processor 16 (vide
Step 3 of the method MS203 determines the presence of the old file name and old file path in the server strata. Upon a No, the flow passes on to MS204. Upon a Yes, the flow passes on to MS205. Step 3 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 4 of the method MS204 is an exact replica of the method of handling a file create event on the server side in accordance with this invention. Function F1S is invoked and the corresponding method steps executed.
Step 5 of the method MS205 determines if the extracted hash value of the retrieved file is zero. Upon a Yes, the flow passes back to MS204, invoking Function F1S. Upon a No, the flow passes on to MS206. Step 5 is executed on Operation Processor 16 (vide
Step 6 of the method MS206 determines if the new hash value equals the old hash value. Upon a No, the flow passes on to MS207. Upon a Yes, the flow passes on to MS208. Step 6 is executed on Operation Processor 16 (vide
Step 7 of the method MS207 is an exact replica of the method of handling a file modify event on the server side in accordance with this invention. Function F2S is invoked and the corresponding method steps executed. Upon successful execution of the method steps, the flow passes on to MS208.
Step 8 of the method MS208 updates the server strata and substitutes the old file name and old file path with the new file name and new file path. Upon successful update, the flow passes on to MS209. Step 8 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 9 of the method MS209 adds one more entry to the server strata with the old file name, old file path and the old hash value. The flow ends from this step. Step 9 is executed on Operation Processor 16 and Server Strata 17 (vide
The embodiment of the method of handling a file delete event associated with the client side is a Function F4C that comprises a sequence of method steps as shown in
Step 1 of the method MC301 determines the presence of the file on the client's Virtual Hard Drive VHD 1 (vide
Step 2 of the method MC302 determines the presence of the file on the local client strata. Upon a Yes, the flow passes on to MC303. Upon a No, the User Operation is ignored as the server deletes the case. Step 2 is executed on Event Processor 4 and Client Strata 5 (vide
Step 3 of the method MC303 determines if the file is currently opened by a user. Upon a Yes, the User Operation is ignored. Upon a No, the flow passes on to MC304. Step 3 is executed on Event Processor 4 and Open File DB 10 (vide
Step 4 of the method MC304 deletes the entry from the local client strata. Upon successful deletion, the flow passes on to MC305. Step 4 is executed on Event Processor 4 and Client Strata 5 (vide
Step 5 of the method MC305 inserts a ‘File Delete’ request in ClientReqAcceptor Q1 (vide
The embodiment of the method of handling a file delete event associated with the server side is a Function F4S that comprises a sequence of method steps as shown in
Step 1 of the method MS301 marks the file hash code as zero. The flow passes on to MS302. Step 1 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 2 of the method MS302 deletes the file from bucket for each corresponding file entry in the server strata. Upon successful deletion, the flow passes on to MS303. Step 2 is executed on Server Strata 17 and Bucket 18 (vide
Step 3 of the method MS303 compares the client strata with the server strata in terms of file entry records. Upon successful compare, the flow passes on to MS304. Step 3 is executed on Strata Downloader 12 and Strata Comparator 11 (vide
Step 4 of the method MS304 updates the strata. Upon successful and correct update, the flow passes on to MS305. Step 4 is executed on Client Strata 5 (vide
Step 5 of the method MS305 deletes the file from the client's virtual hard drive VHD 1 (vide
The embodiment of the method of handling a file edit event associated with the client side is a Function F5C that comprises a sequence of method steps as shown in
Step 1 of the method MC401 determines if the file opened by the user is closed. Upon a Yes, the flow passes on to MC402. Upon a No, the system loops through till the file opened by the user is closed. Step 1 is executed on Open File Identifier 8 (vide
Step 2 of the method MC402 determines if a file update is pending upon closure. Upon a Yes, the User Operation is ignored. Upon a No, the flow passes on to MC403. Step 2 is executed on Open File Processor 7 (vide
Step 3 of the method MC403 opens the file and retrieves the relevant hash value. Upon successful retrieval of the hash value, the flow passes on to MC404. Step 3 is executed on Open File Processor 7 (vide
Step 4 of the method MC404 determines if the file is present on the local client strata. Upon a Yes, the flow passes on to MC405. Upon a No, the flow passes on to MC408. Step 4 is executed on Client Strata 5 (vide
Step 5 of the method MC405 determines the difference in the retrieved hash value with the original file hash value. If the two are determined different, the flow passes on to MC406. If the two are not determined different, the User Operation is ignored (there being no ‘File Edit’ command upon the equality of the hash values in question) and the flow ends from this step. Step 5 is executed on Open File Processor 7 (vide
Step 6 of the method MC406 updates the local client strata upon determination of the difference in retrieved hash value and the original hash value of the file associated with this User Operation. Upon the successful and correct update of the client strata, the flow passes on to MC407. Step 6 is executed on Client Strata 5 and Open File Processor 7 (vide
Step 7 of the method MC407 inserts a ‘File Modify’ request on FileUploadQueue Q2 (vide
Step 8 of the method MC408 inserts a new row for file entry upon determination that the file associated with this User Operation is not present on the local client strata.
Upon successful insertion of the new row, the flow passes on to MC409. Step 8 is executed on Client Strata 5 (vide
Step 9 of the method MC409 inserts a ‘File Create’ request on FileUploadQueue Q2 (vide
The embodiment of the method of handling a folder create event associated with the client side is a Function F6C that comprises a sequence of method steps as shown in
Step 1 of the method MC501 determines the folder's presence on local client strata. Upon a Yes, the User Operation is ignored as the folder in question to be created already exists. Upon a No, the flow passes on to MC502. Step 1 is executed on Client Strata 5 (vide
Step 2 of the method MC502 determines the emptiness of the folder upon determination that the folder associated with the User Operation is not present on local client strata. If the folder is empty, the flow passes on to MC506. If the folder is not empty, the flow passes on to MC503. Step 2 is executed on Event Processor 4 (vide
Step 3 of the method MC503 involves browsing the folder and retrieving all files and subdirectories present in the folder associated with the User Operation. Upon successful and correct retrieval of all the folder components, the flow passes on to MC504. Step 3 is executed on Event Processor 4 (vide
Step 4 of the method MC504 inserts the relevant requests for each of the folder components on ClientReqAcceptor Q1 (vide
Step 5 of the method MC505 inserts a ‘Directory Create’ request on ClientReqAcceptor Q1 (vide
Step 6 of the method MC506 updates the local client strata by adding a new entry for the current folder. Upon successful update of the local client strata, the flow passes on to MC507. Step 6 is executed on Client Strata 5 (vide
Step 7 of the method MC507 inserts a ‘Folder Create’ request FileUploadQueue Q2 (vide
The embodiment of the method of handling a folder create event associated with the server side is a Function F6S that comprises a sequence of method steps as shown in
Step 1 of the method MS501 determines the folder's presence on local server strata. Upon a No, the User Operation is ignored. Upon a Yes, the flow passes on to MS502. Step 1 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 2 of the method MS502 determines if the hash value of the retrieved folder is zero upon the determination of the folder's presence of the local server strata. If the hash value is non-zero, the User Operation is ignored. If the hash value is zero, the flow passes on to MS503. Step 2 is executed on Operation Processor 16 (vide
Step 3 of the method MS503 updates the local server strata. Upon the successful and correct update of the server strata, the flow passes on to MS504. Step 3 is executed on Server Strata 17 (vide
Step 4 of the method MS504 adds a new entry to the server strata with a hash value of 99. Upon completion of the new entry to the strata, the flow ends from this step. Step 4 is executed on Server Strata 17 (vide
The embodiment of the method of handling a folder rename event associated with the client side is a Function F7C that comprises a sequence of method steps as shown in
Step 1 of the method MC601 determines if the old folder name is present on the local client strata for the associated User Operation. Upon a No, the flow passes on to MC605. Upon a Yes, the flow passes on to MC602. Step 1 is executed on Event Processor 4 (vide
Step 2 of the method MC602 determines if the new folder name is present on the local client strata for the associated User Operation. Upon a Yes, the User Operation is ignored. Upon a No, the flow passes on to MC603. Step 2 is executed on Event Processor 4 (vide
Step 3 of the method MC603 changes the entry in local client strata string containing the old folder name with the new folder name. Step 3 is executed on Client Strata 5 (vide
Step 4 of the method MC604 inserts a ‘Folder Rename’ request on FileUploadQueue Q2 (vide
Step 5 of the method MC605 is an exact replica of the method of handling a folder create event on the client side in accordance with this invention. Function F6C is invoked and the corresponding method steps executed.
The embodiment of the method of handling a folder rename event associated with the server side is a Function F7S that comprises a sequence of method steps as shown in
Step 1 of the method MS601 replaces the string of the old folder name with the new folder name for all files and subdirectories except where the hash value is zero. Upon successful replacement, the flow passes on to MS602. Step 1 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 2 of the method MS602 changes the file and all subfolder paths. Upon successful and correct change, the flow passes on to MS603. Step 2 is executed on Operation Processor 16 and Server Strata 17 (vide
Step 3 of the method MS603 adds new entries for those with zero hash values for all sub-folders, files and the current folder. Upon successful addition, the flow ends from this step. Step 3 is executed on Operation Processor 16 and Server Strata 17 (vide
Why settle for a 15% margin? Sell CloudFileSync and you could earn profit margins of up to 300%*.
