WO2017028688A1 - 文件读写方法、装置和系统 - Google Patents

文件读写方法、装置和系统 Download PDF

Info

Publication number
WO2017028688A1
WO2017028688A1 PCT/CN2016/093493 CN2016093493W WO2017028688A1 WO 2017028688 A1 WO2017028688 A1 WO 2017028688A1 CN 2016093493 W CN2016093493 W CN 2016093493W WO 2017028688 A1 WO2017028688 A1 WO 2017028688A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
lock
server
information
user
Prior art date
Application number
PCT/CN2016/093493
Other languages
English (en)
French (fr)
Inventor
占怀旻
董华凌
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2017028688A1 publication Critical patent/WO2017028688A1/zh
Priority to US15/895,927 priority Critical patent/US10338917B2/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/172Caching, prefetching or hoarding of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/162Delete operations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/176Support for shared access to files; File sharing support
    • G06F16/1767Concurrency control, e.g. optimistic or pessimistic approaches
    • G06F16/1774Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/903Querying
    • G06F16/90335Query processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/33Intelligent editors

Definitions

  • the present application relates to the field of WebIDE (WebIDE is a kind of webpage that allows users to edit code on a page), and particularly relates to a method, device and system for reading and writing files.
  • WebIDE is a kind of webpage that allows users to edit code on a page
  • GIT Distributed Version Control System
  • SVN Subversion, Open Source Version Control System
  • Some WebIDE development environments have enabled developers to write and submit code files in the browser to solve the problem of low efficiency caused by high operating costs.
  • some multi-person collaborative development systems use a client-side caching method, in which multiple developers record operations on the same file in their own client cache, and then submit their own cache operations to the server, server. Get the cache operation of each client, merge it into a complete operation, and then update the file.
  • the program has the following problems:
  • the developer's read and write permissions to the file are not properly controlled. Since the same file can be opened in multiple browsers, or multiple developers open the same file for writing, they are the same at the same time. In the case of a file, there may be cases where different developers open and write different content, resulting in conflicts in the contents of the file when the file is submitted by a number of different developers, or the contents of the file overlap each other. The situation has severely limited the development of multiple developers in multi-person collaborative development;
  • the client needs to have a cache, and needs sufficient authority to operate the cache system.
  • the ios system strictly controls the user rights, or the user manually closes the permissions, and the developer cannot operate.
  • the present application aims to solve at least one of the technical problems in the related art to some extent.
  • the first object of the present application is to propose a file reading and writing method, the file reading and writing method.
  • a second object of the present application is to provide a file reading and writing device.
  • a third object of the present application is to propose a file reading and writing system.
  • the first aspect of the present application provides a file reading and writing method, including the steps of: receiving an access request, and acquiring file identification information and first user identification information according to the access request; Querying the lock file corresponding to the file identifier information, if the lock file corresponding to the file identifier information is not queried, obtaining the first original file corresponding to the file identifier information from the file server; and according to the first user identifier information Generating a lock file with the first original file, and submitting the lock file to the cache server; and receiving an edit operation for the first original file, and submitting the edited first original file to the Caching the server to cause the cache server to update the locked file according to the edited first original file.
  • the file reading and writing method of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a caching mechanism to lock the file, thereby making the user
  • the file operation process has the exclusive operation right of the file, which avoids conflicts between the content submitted by multiple users when the same file is operated, so that the WebIDE system can play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • the second aspect of the present application provides a file reading and writing apparatus, including: a first receiving module, configured to receive an access request; and a first obtaining module, the user acquiring file identification information according to the access request and a first user identifier information; a query module, configured to query a lock file corresponding to the file identifier information in a cache server; and a second obtaining module, configured to: when the query module does not query the lock file corresponding to the file identifier information And acquiring, by the file server, a first original file corresponding to the file identifier information, and a generating module, configured to generate a lock file according to the first user identifier information and the first original file, and a submitting module, configured to: And the second receiving module is configured to receive an editing operation for the first original file, where the submitting module submits the edited first original file to the cache server, In order to The cache server updates the lock file according to the edited first original file.
  • the file reading and writing device of the embodiment of the present invention implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to lock the file, thereby making the user
  • the file operation process has the exclusive operation right of the file, which avoids conflicts between the content submitted by multiple users when the same file is operated, so that the WebIDE system can play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • the third aspect of the present application provides a file reading and writing system, including: a WebIDE server, a cache server, and a file server, wherein the WebIDE server is configured to receive an access request, and according to the access request.
  • the file reading and writing system of the embodiment of the present invention implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to lock the file, thereby making the user
  • the file operation process has the exclusive operation right of the file, which avoids conflicts between the content submitted by multiple users when the same file is operated, so that the WebIDE system can play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • FIG. 1 is a flow chart of a file reading and writing method according to an embodiment of the present application.
  • FIG. 2 is a flow chart of a file reading and writing method according to a specific embodiment of the present application.
  • FIG. 3 is a flow chart of a file reading and writing method according to another embodiment of the present application.
  • FIG. 4 is a flowchart of a file reading and writing method according to another embodiment of the present application.
  • FIG. 5 is a flowchart of a file reading and writing method according to another embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a file reading and writing device according to an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application.
  • first and second are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated.
  • features defining “first” and “second” may include one or more of the features either explicitly or implicitly.
  • the meaning of "a plurality” is two or more unless specifically and specifically defined otherwise.
  • FIG. 1 is a flow chart of a file reading and writing method according to an embodiment of the present application.
  • the file reading and writing methods include:
  • S101 Receive an access request, and obtain file identification information and first user identification information according to the access request.
  • a WebIDE server can provide a user interface for editing files, perform operations in the cache server, or interact with the cache server and the file server.
  • the file server is used to store the code file of the file.
  • the GIT server is used to store the code file of the GIT file
  • the SVN server is used to store the code file of the SVN file.
  • the cache server is a file that uses a caching mechanism to implement storage locking. For example, it can be a noSql cache server. It can also be Redis, Tair or other cache server.
  • the WebIDE server, the cache server, and the file server may be a single server or a server cluster composed of multiple servers.
  • the WebIDE server receives the access request sent by the user A to access a certain file, and obtains the file identification information of the file and the user identification information of the user A.
  • the file identifier information is used to query the unique identifier of the file on the server.
  • the file identifier information may be a file path, a file MD5 (Message Digest Algorithm 5), or the like.
  • the user identification information is a unique identifier for verifying the identity of the user, for example, the user identification information may be a user ID (identity identification number) or the like.
  • the WebIDE server queries the cache server according to the file identifier information whether there is a file corresponding to the file identifier information, wherein the file is locked in the cache server, that is, the file is locked. That is to say, when user A requests to access the file, the file is not directly obtained from the file server, but the cache server is first queried whether there is a file that has been locked. If there is no file that has been locked in the cache server, then Then get the file from the file server.
  • the WebIDE server finds the corresponding original file according to the file identification information in the file server, and acquires the original file.
  • the WebIDE server presents the file content of the original file to the user A, and simultaneously locks the original file according to the user identification information of the user A to generate a lock file containing the original file and the user identification information. Then, the WebIDE server uses the file identification information as the identifier of the lock file, and submits the lock file to the cache server for storage.
  • the WebIDE server After the lock file is stored in the cache server, if the WebIDE server receives the request sent by the user B to access the file, the WebIDE server first queries the cache server for the corresponding file in the same manner. Lock the file. If the WebIDE server queries the corresponding lock file, because there is a lock file in the cache server, User B does not allow the file to be edited or edited when the file is locked. Thus, it is possible to prevent user A and user B from editing the file at the same time, resulting in editing. The content of the conflicting issues.
  • S104 Receive an editing operation for the first original file, and submit the edited first original file to the cache server, so that the cache server updates the lock file according to the edited first original file.
  • the user A can edit the file content of the original file.
  • the WebIDE server submits the edited original file plus the user identification information to the cache server. That is, the WebIDE server saves the edited content of User A to the lock file of the cache server.
  • the WebIDE server uses the GitLab API or the Svn API to read and write files, and uses ACE and other open source.
  • the JS framework implements the presentation of file content.
  • the cache used in the cache server can use SSD (Solid State Drives) as the cache persistence space to get more storage space, or use a cache scheme such as Tair cluster. Since the above schemes are mature technologies, they are not repeated here.
  • the file reading and writing method of the embodiment of the present application implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a caching mechanism to lock the file, thereby making the user
  • the file operation process has the exclusive operation right of the file, which avoids conflicts between the content submitted by multiple users when the same file is operated, so that the WebIDE system can play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • FIG. 2 is a flow chart of a file reading and writing method according to a specific embodiment of the present application.
  • the file reading and writing methods include:
  • S201 Receive an access request, and obtain file identifier information and first user identifier information according to the access request.
  • the WebIDE server queries the corresponding lock file in the cache server, the original file stored on the file server is currently locked, and the WebIDE server obtains the user identification information of the locked file, and determines the user identifier of the user A. Whether the information and the user identification information of the locked file match, if If the user identification information of the user A matches the user identification information of the lock file, the WebIDE server determines that the user A has the right to acquire the lock file and edit it.
  • generating prompt information for rejecting the acquisition of the locked file is generated.
  • the user B accesses the lock file in the cache server, the user identifier information of the user B and the user identifier information of the lock file do not match, that is, the lock file is locked by the user A, and the WebIDE server determines that the user B does not have the permission. Get the lock file for editing, and generate a prompt message to prompt user B.
  • the WebIDE server may provide User B with a copy of the lock file, and User B may edit the copy to enable User A.
  • the WebIDE server submits according to the conflict edited by User B after processing the conflict between the copy and the locked file edited by User A.
  • User B can be provided with a more friendly operation mode.
  • S204 Receive an edit operation for the locked file, and submit the edited lock file to the cache server, so that the cache server updates the lock file according to the edited lock file.
  • the WebIDE server presents the file content of the locked file to the user A, and the user A can edit the file content.
  • the WebIDE server submits the edited lock file plus the user identification information.
  • the WebIDE server saves the edited content of User A to the lock file of the cache server.
  • the lock file stored by the user A in the cache server is persistently maintained.
  • the user A switches from one client to another, the user A can be based on the user A.
  • the user representation information and file identification information are again read from the lock file in the cache server for editing.
  • FIG. 3 is a flow chart of a file reading and writing method according to another embodiment of the present application.
  • the file reading and writing methods include:
  • S301 Receive an access request, and obtain file identifier information and first user identifier information according to the access request.
  • S302 Query the lock file corresponding to the file identifier information in the cache server. If the lock file corresponding to the file identifier information is not queried, obtain the first original file corresponding to the file identifier information from the file server.
  • S304 Receive an editing operation for the first original file, and submit the edited first original file to the cache server, so that the cache server updates the lock file according to the edited first original file.
  • S305 Obtain a second original file from the file server, and determine whether the first submission information of the locked file in the cache server matches the second submission information of the second original file, and if the first submission information matches the second submission information, The lock file is submitted to the file server so that the file server replaces the second original file with the lock file.
  • the WebIDE server after updating the lock file in the cache server according to the content edited by the user A, the WebIDE server obtains the original file saved in the file server from the file server again, and obtains the commit information of the original file, if the file is locked in the cache server.
  • the submission information matches the submission information of the original file in the file server, and the WebIDE server asynchronously submits the updated lock file to the file server, and replaces the original file in the file server with the updated lock file.
  • the original file in the file server has been updated, for example, the user updates the original file through the client of the file server. Then the WebIDE server saves the content of the locked file as a copy, and obtains the content of the original file, and updates the content of the locked file according to the content of the original file. After the user A resolves the conflict between the content of the lock file and the content of the original file, the WebIDE server updates the commit information of the lock file in the cache server to the commit information of the original file in the file server. The WebIDE server then asynchronously submits the updated lock file to the file server, replacing the original file in the file server with the updated lock file.
  • FIG. 4 is a flow chart of a file reading and writing method according to another embodiment of the present application.
  • the file reading and writing methods include:
  • S401 Receive an access request, and obtain file identification information and first user identification information according to the access request.
  • the slave cache Get the lock file in the server.
  • S404 Receive an editing operation for the locked file, and submit the edited locked file to the cache server. In order for the cache server to update the lock file based on the edited lock file.
  • S405. Receive an unlock request for the locked file in the cache server, and delete the lock file from the cache server when determining that the first user identifier information matches the second user identifier information corresponding to the lock file.
  • the user A may send a request to unlock the lock file.
  • the WebIDE server After receiving the unlock request sent by the user A, the WebIDE server prompts the user to unlock the lock file and prompts the user whether Submit the lock file to the file server before unlocking.
  • the corresponding lock file is found in the cache server according to the file identifier information, and it is determined whether the user identifier information corresponding to the lock file matches the user identifier information of the user A. If the user identification information corresponding to the lock file matches the user identification information of user A, the WebIDE server deletes the lock file from the cache server.
  • the WebIDE server further provides the user B with the exclusive operation right of the separate operation file according to the methods of steps S401-S404.
  • FIG. 5 is a flowchart of a file reading and writing method according to another embodiment of the present application.
  • the file reading and writing method includes:
  • S501 Receive an access request, and obtain file identification information and first user identification information according to the access request.
  • the slave cache Get the lock file in the server.
  • user B can choose to steal the lock and directly read and write the lock file.
  • User A of the privilege becomes user B with privilege. That is, the user B sends a replacement request for the user identification information corresponding to the lock file in the cache server, and after receiving the replacement request sent by the user B, the WebIDE server replaces the user identification information of the lock file with the user identifier of the user B. Information and generate a user who locks the file The prompt information that the information is replaced is indicated to prompt the user A.
  • the WebIDE server presents the file content of the locked file to the user B, and the user B can edit the file content.
  • the WebIDE server adds the edited lock file to the user B user.
  • the identification information is submitted to the cache server. That is, the WebIDE server saves the edited content of User B to the lock file of the cache server.
  • the file reading and writing method of the embodiment of the present invention provides functions such as file locking, file unlocking, and lock-up for the user, and solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other, and the cache server can be used to save the locked file. Solve the problem of information synchronization in multiple WebIDE servers, so that multi-person collaborative development can fully exploit the advantages of fast and environmentally unrestricted.
  • the present application also proposes a file reading and writing device.
  • FIG. 6 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application.
  • the file reading and writing apparatus includes: a first receiving module 101, a first obtaining module 102, a query module 103, and a second acquiring module 104.
  • the first receiving module 101 is configured to receive an access request.
  • the first obtaining module 102 acquires file identification information and first user identification information according to the access request.
  • the first receiving module 101 receives the access request sent by the user A to access a certain file, and the first obtaining module 102 acquires the file identification information of the file and the user identification information of the user A.
  • the file identifier information is used to query the server for a unique identifier of the file.
  • the file identifier information may be a file path, an MD5 of the file, or the like.
  • the user identification information is a unique identifier for verifying the identity of the user, for example, the user identification information may be a user ID or the like.
  • the query module 103 is configured to query the cache file for the lock file corresponding to the file identifier information.
  • the second obtaining module 104 is configured to: when the query module 103 does not query the lock file corresponding to the file identifier information, obtain the first original file corresponding to the file identifier information from the file server. Specifically, the query module 103 queries, in the cache server, whether there is a file corresponding to the file identification information according to the file identification information, wherein the file is in a locked state, that is, a locked file. That is to say, when user A requests to access the file, the file is not directly obtained from the file server, but the cache server is first queried whether there is a file that has been locked.
  • the second obtaining module 104 finds the corresponding original file according to the file identification information in the file server, and acquires the original file.
  • the generating module 105 is configured to generate a lock file according to the first user identification information and the first original file.
  • the submission module 106 is for submitting the lock file to the cache server. Specifically, the generating module 105 presents the file content of the original file to the user A, and the generating module 105 locks the original file according to the user identification information of the user A to generate a locked file containing the original file and the user identification information. Then, the submitting module 106 uses the file identification information as the identifier of the lock file, and submits the lock file to the cache server for storage.
  • the second receiving module 107 is configured to receive an editing operation for the first original file, where the submitting module 106 submits the edited first original file to the cache server, so that the cache server locks the file according to the edited first original file pair.
  • Update Specifically, the user A can edit the file content of the original file.
  • the second receiving module 107 receives the editing operation of the user, and the submitting module 106 adds the edited original file to the user identifier.
  • the information is submitted to the cache server. That is to say, the content edited by the user A is saved to the lock file of the cache server.
  • the file reading and writing device of the embodiment of the present invention implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to lock the file, thereby making the user
  • the file operation process has the exclusive operation right of the file, which avoids conflicts between the content submitted by multiple users when the same file is operated, so that the WebIDE system can play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • FIG. 7 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application.
  • the file reading and writing apparatus includes: a first receiving module 101, a first obtaining module 102, a query module 103, and a second acquiring module.
  • the receiving module 114, the replacement module 115 and the second prompting module 116 includes: a first receiving module 101, a first obtaining module 102, a query module 103, and a second acquiring module.
  • the first determining module 108 is configured to determine, when the query module 103 queries the lock file corresponding to the file identifier information, whether the first user identifier information matches the second user identifier information corresponding to the lock file.
  • the second obtaining module 104 is further configured to: when the first determining module 108 determines that the first user identification information matches the second user identification information, acquire the locking file from the cache server. Specifically, if the query module 103 queries the corresponding lock file in the cache server, it indicates that the original file stored on the file server is currently in a locked state, and the lock file is obtained.
  • the first determining module 108 determines whether the user identification information of the user A and the user identification information of the locking file match, and if the first determining module 108 determines that the user identification information of the user A matches the user identification information of the locking file, Then user A has the right to acquire the lock file and edit it. Therefore, the second obtaining module 104 acquires the lock file from the cache server.
  • the first prompting module 109 is configured to generate prompt information for rejecting the acquisition of the lock file when the first determining module 108 determines that the first user identification information does not match the second user identification information. Specifically, if the user B accesses the lock file in the cache server, the first determining module 108 determines that the user identifier information of the user B and the user identifier information of the lock file do not match, that is, the lock file is locked by the user A, A judging module 108 judges that the user B does not have the right to acquire the lock file for editing, and the first prompting module 109 generates the prompting information to prompt the user B.
  • the file reading and writing apparatus further includes a second judging module 110 and an updating module 111.
  • the second obtaining module 104 is further configured to acquire the second original file from the file server.
  • the second determining module 110 is configured to determine whether the first submission information of the locked file in the cache server matches the second submission information of the second original file.
  • the submitting module 106 is further configured to: when the second determining module 110 determines that the first submitting information matches the second submitting information, submit the locked file to the file server, so that the file server replaces the second original file with the locked file.
  • the second obtaining module 104 acquires the original file saved in the file server from the file server, and obtains the submit information of the original file. If the second judging module 110 determines that the commit information of the lock file in the cache server matches the commit information of the original file in the file server, the submitting module 106 asynchronously submits the updated lock file to the file server, and replaces the original file in the file server. The updated lock file.
  • the update module 111 is configured to: when the second determining module 110 determines that the first submission information does not match the second submission information, update the lock file according to the second original file, and update the first submission information according to the second submission information, where The submission module 106 is also used to submit the updated lock file to the file server. Specifically, if the second judging module 110 determines that the commit information of the lock file in the cache server does not match the commit information of the original file in the file server, the original file in the file server has been updated, for example, the client pair of the user through the file server When the original file is updated, the update module 111 saves the content of the locked file as a copy, and acquires the content of the original file, and updates the content of the locked file according to the content of the original file.
  • the submitting module 106 updates the commit information of the lock file in the cache server to the commit information of the original file in the file server.
  • the submitting module 106 then asynchronously submits the updated lock file to the file server, replacing the original file in the file server with the updated lock file.
  • the file reading and writing device further includes a third receiving module 112 and an unlocking module 113.
  • the third receiving module 112 is configured to receive an unlock request for a locked file in the cache server.
  • the unlocking module 113 is configured to delete the lock file from the cache server when the first determining module 108 determines that the first user identifier information matches the second user identifier information corresponding to the lock file.
  • the user A may send a request to unlock the lock file, and after receiving the unlock request sent by the user A, the third receiving module 112 prompts the user to lock the lock.
  • the file is unlocked and prompts the user to submit the lock file to the file server before unlocking.
  • the first determining module 108 finds the corresponding lock file in the cache server according to the file identifier information, and determines whether the user identifier information corresponding to the lock file matches the user identifier information of the user A. If the first determining module 108 determines that the user identification information corresponding to the locked file matches the user identification information of the user A, the unlocking module 113 deletes the locked file from the cache server.
  • the file reading and writing device further includes a fourth receiving module 114, a replacement module 115, and a second prompting module 116.
  • the fourth receiving module 114 is configured to receive a replacement request for the second user identification information.
  • the replacement module 115 is configured to replace the second user identification information with the first user identification information according to the replacement request.
  • the second prompting module 116 is configured to generate prompt information that the second user identification information is replaced. Specifically, if user B does not have permission to acquire the lock file for editing, and user B urgently needs to edit the lock file, and the file is locked by user A, user B can choose to steal the lock and directly read and write the lock file. User A of the privilege becomes user B with privilege.
  • the user B sends a replacement request for the user identification information corresponding to the lock file in the cache server, and after receiving the replacement request sent by the user B, the fourth receiving module 114 replaces the user identification information of the lock file.
  • the second prompting module 116 For the user identification information of the user B, the second prompting module 116 generates the prompt information that the user identification information of the locked file is replaced to prompt the user A.
  • the file reading and writing device of the embodiment of the present invention provides functions such as file locking, file unlocking, and lock-up for the user, and solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other, and the cache server can be used to save the locked file. Solve the problem of information synchronization in multiple WebIDE servers, so that multi-person collaborative development can fully exploit the advantages of fast and environmentally unrestricted.
  • the present application also proposes a file reading and writing system.
  • FIG. 8 is a schematic structural diagram of a file reading and writing apparatus according to an embodiment of the present application.
  • the file reading and writing system includes: a WebIDE server 1, a cache server 2, and a file server 3.
  • the WebIDE server 1 is configured to receive the access request, and obtain the file identification information and the first user identification information according to the access request, and query the lock file corresponding to the file identification information in the cache server 2, if the file identification information is not queried.
  • the lock file, the file corresponding to the file identifier information is obtained from the file server 3 An original file, and generating a lock file according to the first user identification information and the first original file, and submitting the lock file to the cache server 2, and receiving an edit operation for the first original file, and the edited first original file Submit to cache server 2; and
  • the cache server 2 is configured to store the lock file and update the lock file according to the edited first original file.
  • the WebIDE server 1 is further configured to: when the lock file corresponding to the file identifier information is queried, determine whether the first user identifier information matches the second user identifier information corresponding to the lock file, if the first user When the identification information matches the second user identification information, the lock file is obtained from the cache server 2.
  • the WebIDE server 1 is further configured to generate prompt information for rejecting the acquisition of the lock file when the first user identification information does not match the second user identification information.
  • the file server 3 stores a second original file, wherein the second original file is an updated version of the first original file
  • the WebIDE server 1 is further configured to acquire the second original file from the file server 3, And determining whether the first submission information of the lock file in the cache server 2 matches the second submission information of the second original file, and when the first submission information matches the second submission information, submitting the lock file to the file server 3.
  • the file server 3 is also used to replace the second original file with a lock file.
  • the WebIDE server 1 is further configured to: when the first submission information does not match the second submission information, update the lock file according to the second original file, and update the first submission according to the second submission information. Information, and submit the updated lock file to file server 3.
  • the file server 3 is also used to replace the second original file with the updated lock file.
  • the WebIDE server 1 is further configured to receive an unlock request for the locked file in the cache server 2, and when determining that the first user identifier information matches the second user identifier information corresponding to the lock file, the slave cache The lock file is deleted in server 2.
  • the WebIDE server 1 is further configured to receive a replacement request for the second user identification information, and replace the second user identification information with the first user identification information according to the replacement request, and generate the second user identifier. A message that the information was replaced.
  • the implementation and function of the file reading and writing system according to the embodiment of the present invention can be referred to the implementation manner of the file reading and writing method and the file reading and writing device in the above embodiment. To reduce redundancy, no further details are provided herein.
  • the file reading and writing system of the embodiment of the present invention implements a file locking mechanism suitable for the WebIDE system by using a cache server, and uses a cache server as a buffer between the file server and the WebIDE server, and uses a cache mechanism to lock the file, thereby making the user
  • the exclusive operation right of the file during the operation of the file avoids The content submitted by multiple users when operating on the same file conflicts with each other, enabling the WebIDE system to play a greater role in multiple collaborative development processes.
  • using the caching mechanism to achieve file locking is less expensive than modifying the file server's database each time, and the caching mechanism can handle multiple files more flexibly, generate different copies of the same file, etc., giving the user more Good experience.
  • the user is provided with functions such as file locking, file unlocking, and lock-up, which solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other.
  • functions such as file locking, file unlocking, and lock-up, which solves the problem that the content submitted by the multi-person collaborative development conflicts and covers each other.
  • using the cache server to save the locked file can solve the problem in multiple WebIDE servers.
  • the problem of synchronization enables multi-person collaborative development to take full advantage of the fast and environmentally unrestricted advantages.
  • portions of the application can be implemented in hardware, software, firmware, or a combination thereof.
  • multiple steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system.
  • a suitable instruction execution system For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques well known in the art: having logic gates for implementing logic functions on data signals. Discrete logic circuits, application specific integrated circuits with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

一种文件读写方法、装置和系统,该文件读写方法包括:接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息(S101);在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件(S102);根据第一用户标识信息和第一原始文件生成锁定文件,并将锁定文件提交至缓存服务器(S103);以及接收针对第一原始文件的编辑操作,并将编辑后的第一原始文件提交至缓存服务器(S104)。文件读写方法使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。

Description

文件读写方法、装置和系统
本申请要求2015年08月14日递交的申请号为201510500501.0、发明名称为“文件读写方法、装置和系统”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及WebIDE(WebIDE是一类让用户可以在页面上编辑代码的网页)开发技术领域,尤其涉及一种文件读写方法、装置和系统。
背景技术
GIT(分布式版本控制系统)和SVN(Subversion,开放源代码的版本控制系统)是开发过程中常用的文件版本控制工具,常用于团队开发任务中,但是这两种工具对系统、环境以及命令熟练度的要求比较高,造成开发人员在使用时开发效率低。
目前,已经有部分WebIDE开发环境(例如国内的Coding.net)让开发人员可以在浏览器中编写并提交代码文件,以解决操作成本高带来的效率低的问题。例如,一些多人协同开发的系统采用的是客户端缓存的方法,即多个开发人员分别在自己的客户端缓存中记录对同一个文件的操作,然后将自己的缓存操作提交到服务器,服务器获取各个客户端的缓存操作后将其合并为一个完整的操作,再对文件进行更新。然而,该方案存在以下问题:
(1)开发人员对文件的读写权限并没有妥善被控制,由于可以在多个浏览器中打开同一个文件进行编写,或者多个开发人员打开同一个文件进行编写,因此在同一时间对于同一个文件而言可能会存在被不同的开发人员打开并写入不同的内容的情况,导致在多个不同的开发人员编写后提交文件时文件的内容存在冲突,或者是文件的内容出现相互覆盖的情况,严重限制了多个开发人员在多人协作开发中的发挥;
(2)客户端需要有缓存,且需要有足够的权限操作缓存系统,例如ios系统对用户权限做严格控制,或者用户手动关闭了权限,开发人员便会无法进行操作;
(3)文件修改的内容都保存在客户端,如果开发人员修改了数据但还没来得及提交到服务器,此时用户切换客户端就会造成数据丢失;
(4)所有的操作数据都存储在客户端缓存,开发人员如果有权限即可随意修改缓存 数据,安全性差。
发明内容
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。
为此,本申请的第一个目的在于提出一种文件读写方法,该文件读写方法。
本申请的第二个目的在于提出一种文件读写装置。
本申请的第三个目的在于提出一种文件读写系统。
为达上述目的,本申请第一方面实施例提出了一种文件读写方法,包括以下步骤:接收访问请求,并根据所述访问请求获取文件标识信息和第一用户标识信息;在缓存服务器中查询所述文件标识信息对应的锁定文件,如果未查询到所述文件标识信息对应的锁定文件,则从文件服务器获取所述文件标识信息对应的第一原始文件;根据所述第一用户标识信息和所述第一原始文件生成锁定文件,并将所述锁定文件提交至所述缓存服务器;以及接收针对所述第一原始文件的编辑操作,并将编辑后的第一原始文件提交至所述缓存服务器,以使所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。
本申请实施例的文件读写方法,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
为达上述目的,本申请第二方面实施例提出了一种文件读写装置,包括:第一接收模块,用于接收访问请求;第一获取模块,用户根据所述访问请求获取文件标识信息和第一用户标识信息;查询模块,用于在缓存服务器中查询所述文件标识信息对应的锁定文件;第二获取模块,用于当所述查询模块未查询到所述文件标识信息对应的锁定文件时,从文件服务器获取所述文件标识信息对应的第一原始文件;生成模块,用于根据所述第一用户标识信息和所述第一原始文件生成锁定文件;提交模块,用于将所述锁定文件提交至所述缓存服务器;以及第二接收模块,用于接收针对所述第一原始文件的编辑操作,其中,所述提交模块将编辑后的第一原始文件提交至所述缓存服务器,以使所述 缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。
本申请实施例的文件读写装置,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
为达上述目的,本申请第三方面实施例提出了一种文件读写系统,包括:WebIDE服务器、缓存服务器和文件服务器,其中,所述WebIDE服务器用于接收访问请求,并根据所述访问请求获取文件标识信息和第一用户标识信息,以及在缓存服务器中查询所述文件标识信息对应的锁定文件,如果未查询到所述文件标识信息对应的锁定文件,则从文件服务器获取所述文件标识信息对应的第一原始文件,并根据所述第一用户标识信息和所述第一原始文件生成锁定文件,并将所述锁定文件提交至所述缓存服务器,以及接收针对所述第一原始文件的编辑操作,并将编辑后的第一原始文件提交至所述缓存服务器;以及所述缓存服务器用于存储所述锁定文件,并根据所述编辑后的第一原始文件对所述锁定文件进行更新。
本申请实施例的文件读写系统,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
本申请附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1是本申请一个实施例的文件读写方法的流程图;
图2是本申请一个具体实施例的文件读写方法的流程图;
图3是本申请另一个具体实施例的文件读写方法的流程图;
图4是本申请另一个具体实施例的文件读写方法的流程图;
图5是本申请另一个具体实施例的文件读写方法的流程图;
图6是本申请一个实施例的文件读写装置的结构示意图;
图7是本申请一个具体实施例的文件读写装置的结构示意图;
图8是本申请一个实施例的文件读写装置的结构示意图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本申请,而不能理解为对本申请的限制。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本申请的实施例所属技术领域的技术人员所理解。
图1是本申请一个实施例的文件读写方法的流程图。
如图1所示,文件读写方法包括:
S101,接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息。
在本申请的实施例中,包括WebIDE服务器、缓存服务器以及文件服务器。其中,WebIDE服务器可以提供编辑文件的用户界面、执行缓存服务器中的操作、或者是和缓存服务器以及文件服务器进行交互。文件服务器用于存储文件的代码文件,例如,GIT服务器用于存储GIT文件的代码文件,SVN服务器用于存储SVN文件的代码文件。而缓存服务器则是使用缓存机制来实现存储锁定的文件,例如,可以是noSql缓存服务器, 也可以是Redis、Tair或者其它缓存服务器。
应当理解的是,WebIDE服务器、缓存服务器以及文件服务器可以是单个的服务器,也可以是由多个服务器组成的服务器集群。
具体地,WebIDE服务器接收用户A发送的访问某个文件的访问请求,并获取该文件的文件标识信息以及用户A的用户标识信息。其中,文件标识信息用于在服务器端查询该文件的唯一标识,例如,文件标识信息可以是文件路径、文件的MD5(Message Digest Algorithm 5,消息摘要算法第五版)等。用户标识信息是用于验证用户身份的唯一标识,例如,用户标识信息可以是用户ID(身份标识号码)等。
S102,在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件。
具体地,WebIDE服务器根据文件标识信息在缓存服务器中查询是否存在与文件标识信息对应的文件,其中,该文件在缓存服务器中是处于锁定状态的,即锁定文件。也就是说,在用户A请求访问文件时,并不直接从文件服务器获取文件,而是先在缓存服务器中查询是否存在已被锁定的文件,如果缓存服务器中不存在已被锁定的文件,则再从文件服务器获取该文件。
如果WebIDE服务器在缓存服务器中未查询到对应的锁定文件,则说明文件服务器上存储的原始文件目前处于未锁定的状态,用户A有权限从文件服务器上获取原始文件并对该原始文件加锁,因此,WebIDE服务器在文件服务器中根据文件标识信息查找到对应的原始文件,并获取该原始文件。
S103,根据第一用户标识信息和第一原始文件生成锁定文件,并将锁定文件提交至缓存服务器。
具体地,WebIDE服务器将原始文件的文件内容展现给用户A,同时根据用户A的用户标识信息锁定该原始文件,以生成包含原始文件和用户标识信息的锁定文件。然后,WebIDE服务器以文件标识信息作为锁定文件的标识,将锁定文件提交至缓存服务器进行存储。
应当理解的是,在将锁定文件存储在缓存服务器之后,如果WebIDE服务器接收到用户B发送的访问该文件的请求后,WebIDE服务器同样会以相同的方式先查询缓存服务器中是否存在该文件对应的锁定文件,如果WebIDE服务器查询到对应的锁定文件,由于缓存服务器中存在锁定文件,因此用户B在文件已被锁定的状态下不允许获取文件或者是对文件进行编辑。由此,可以避免用户A和用户B同时对文件进行编辑导致编辑 的内容相互冲突的问题。
S104,接收针对第一原始文件的编辑操作,并将编辑后的第一原始文件提交至缓存服务器,以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。
具体地,用户A可以对原始文件的文件内容进行编辑,当用户A选择保存编辑后的内容时,WebIDE服务器将编辑后的原始文件加上用户标识信息提交至缓存服务器。也就是说,WebIDE服务器将用户A编辑后的内容保存至缓存服务器的锁定文件中。
应当理解的是,WebIDE服务器从文件服务器读写文件以及将文件内容展现给用户的方式均可采用现有技术实现,例如,WebIDE服务器使用GitLab API或者Svn API实现文件的读写,使用ACE等开源JS框架实现文件内容的展现。而缓存服务器中使用的缓存,可以用SSD(Solid State Drives,固态硬盘)做缓存持久化空间,以得到更大的存储空间,或者使用Tair集群等缓存方案皆可。由于上述方案都是成熟的技术,因此,此处不再复赘。
本申请实施例的文件读写方法,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
图2是本申请一个具体实施例的文件读写方法的流程图。
如图2所示,文件读写方法包括:
S201,接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息。
S202,在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件。
S203,如果查询到文件标识信息对应的锁定文件,则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配,若第一用户标识信息与第二用户标识信息匹配,则从缓存服务器中获取锁定文件。
具体地,如果WebIDE服务器在缓存服务器中查询到对应的锁定文件,则说明文件服务器上存储的原始文件目前处于锁定的状态,则WebIDE服务器获取锁定文件的用户标识信息,并判断用户A的用户标识信息和锁定文件的用户标识信息是否匹配,如果用 户A的用户标识信息和锁定文件的用户标识信息匹配,则WebIDE服务器判断用户A有权限获取锁定文件并进行编辑。
应当理解的是,在用户A读取到锁定文件后,该锁定文件在缓存服务器中仍然继续保持锁定状态。
在本申请的一个实施例中,若第一用户标识信息与第二用户标识信息不匹配,则生成拒绝获取锁定文件的提示信息。具体地,如果是用户B访问缓存服务器中的锁定文件,则用户B的用户标识信息和锁定文件的用户标识信息不匹配,即该锁定文件是用户A锁定的,则WebIDE服务器判断用户B没有权限获取锁定文件进行编辑,生成提示提示信息提示用户B。
在本申请的一个实施例中,如果WebIDE服务器判断用户B没有权限获取锁定文件进行编辑,则WebIDE服务器可以为用户B提供一个锁定文件的副本,用户B可以对副本进行编辑,以使在用户A对锁定文件解锁后,WebIDE服务器根据用户B编辑的副本在处理副本和用户A编辑的锁定文件的冲突之后再进行提交。由此,在用户B没有对锁定文件编辑的权限时,可以为用户B提供一种更加友好的操作方式。
S204,接收针对锁定文件的编辑操作,并将编辑后的锁定文件提交至缓存服务器,以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。
具体地,WebIDE服务器将锁定文件的文件内容展现给用户A,用户A可以对文件内容进行编辑,当用户A选择保存编辑后的内容时,WebIDE服务器将编辑后的锁定文件加上用户标识信息提交至缓存服务器。也就是说,WebIDE服务器将用户A编辑后的内容保存至缓存服务器的锁定文件中。
应当理解的是,由于缓存服务器中缓存文件的持久化特性,用户A在缓存服务器中存储的锁定文件会被持久保持,当用户A从一个客户端切换至另一个客户端时,可以根据用户A的用户表示信息和文件标识信息再次读取缓存服务器中的锁定文件进行编辑。
图3是本申请另一个具体实施例的文件读写方法的流程图。
如图3所示,文件读写方法包括:
S301,接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息。
S302,在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件。
S303,根据第一用户标识信息和第一原始文件生成锁定文件,并将锁定文件提交至缓存服务器。
S304,接收针对第一原始文件的编辑操作,并将编辑后的第一原始文件提交至缓存服务器,以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。
S305,从文件服务器获取第二原始文件,并判断缓存服务器中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配,如果第一提交信息与第二提交信息匹配,则将锁定文件提交至文件服务器,以使文件服务器将第二原始文件替换为锁定文件。
具体地,WebIDE服务器根据用户A编辑的内容对缓存服务器中的锁定文件更新后,从文件服务器再次获取文件服务器中保存的原始文件,并从获取该原始文件的提交信息,如果缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息匹配,则WebIDE服务器将更新后的锁定文件异步提交至文件服务器,将文件服务器中的原始文件替换为更新后的锁定文件。
S306,如果第一提交信息与第二提交信息不匹配,则根据第二原始文件对锁定文件进行更新,并根据第二提交信息更新第一提交信息,以及将更新后的锁定文件提交至文件服务器。
具体地,如果缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息不匹配,说明文件服务器中原始文件已经被更新,例如,用户通过文件服务器的客户端对原始文件进行了更新,则WebIDE服务器将锁定文件的内容保存为副本,并获取原始文件的内容,根据原始文件的内容对锁定文件的内容进行更新。在用户A在解决锁定文件的内容和原始文件的内容之间的冲突之后,WebIDE服务器将缓存服务器中的锁定文件的提交信息更新为文件服务器中原始文件的提交信息。然后,WebIDE服务器将更新后的锁定文件异步提交至文件服务器,将文件服务器中的原始文件替换为更新后的锁定文件。
图4是本申请另一个具体实施例的文件读写方法的流程图。
如图4所示,文件读写方法包括:
S401,接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息。
S402,在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件。
S403,如果查询到文件标识信息对应的锁定文件,则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配,若第一用户标识信息与第二用户标识信息匹配,则从缓存服务器中获取锁定文件。
S404,接收针对锁定文件的编辑操作,并将编辑后的锁定文件提交至缓存服务器, 以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。
S405,接收针对缓存服务器中锁定文件的解锁请求,并在判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时,从缓存服务器中删除锁定文件。
具体地,在用户A对锁定文件编辑完成之后,用户A可以发送对锁定文件进行解锁的请求,WebIDE服务器在接收到用户A发送的解锁请求后,提示用户即将对锁定文件解锁,并提示用户是否在解锁前将锁定文件提交至文件服务器中。在用户A确认对锁定文件解锁之后,根据文件标识信息在缓存服务器中查找到对应的锁定文件,并判断锁定文件对应的用户标识信息是否和用户A的用户标识信息匹配。如果锁定文件对应的用户标识信息和用户A的用户标识信息匹配,则WebIDE服务器从缓存服务器中删除该锁定文件。
应当理解的是,在锁定文件从缓存服务器删除之后,如果用户B请求访问文件,则WebIDE服务器则进一步根据步骤S401-S404的方法为用户B提供单独操作文件的独享操作权。
图5是本申请另一个具体实施例的文件读写方法的流程图。
如图5所示,文件读写方法包括:
S501,接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息。
S502,在缓存服务器中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器获取文件标识信息对应的第一原始文件。
S503,如果查询到文件标识信息对应的锁定文件,则判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配,若第一用户标识信息与第二用户标识信息匹配,则从缓存服务器中获取锁定文件。
S504,若第一用户标识信息与第二用户标识信息不匹配,则生成拒绝获取锁定文件的提示信息。
S505,接收针对第二用户标识信息的替换请求,并根据替换请求将第二用户标识信息替换为第一用户标识信息,以及生成第二用户标识信息被替换的提示信息。
具体地,如果用户B没有权限获取锁定文件进行编辑,而用户B又急需对锁定文件进行编辑,此时该文件被用户A锁定,则用户B可以选择抢锁,直接将具有锁定文件的读写权限的用户A变为用户B具有权限。也就是说,用户B发送对缓存服务器中锁定文件所对应的用户标识信息的替换请求,WebIDE服务器在接收到用户B发送的替换请求后,将锁定文件的用户标识信息替换为用户B的用户标识信息,并生成锁定文件的用户 标识信息被替换的提示信息以提示用户A。
S506,接收针对锁定文件的编辑操作,并将编辑后的锁定文件提交至缓存服务器,以使缓存服务器根据编辑后的锁定文件对锁定文件进行更新。
具体地,WebIDE服务器将锁定文件的文件内容展现给用户B,用户B可以对文件内容进行编辑,当用户B选择保存编辑后的内容时,WebIDE服务器将编辑后的锁定文件加上用户B的用户标识信息提交至缓存服务器。也就是说,WebIDE服务器将用户B编辑后的内容保存至缓存服务器的锁定文件中。
本申请实施例的文件读写方法,为用户提供文件锁定、文件解锁和抢锁等功能,解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题,同时使用缓存服务器保存锁定文件可以解决多个WebIDE服务器中信息不同步的问题,使得多人协同开发时能够充分发挥快速、不受环境限制的优势。
为了实现上述实施例,本申请还提出一种文件读写装置。
图6是本申请一个实施例的文件读写装置的结构示意图,如图6所示,文件读写装置包括:第一接收模块101、第一获取模块102、查询模块103、第二获取模块104、生成模块105、提交模块106和第二接收模块107。
具体地,第一接收模块101用于接收访问请求。第一获取模块102用户根据访问请求获取文件标识信息和第一用户标识信息。具体而言,第一接收模块101接收用户A发送的访问某个文件的访问请求,第一获取模块102获取该文件的文件标识信息以及用户A的用户标识信息。其中,文件标识信息用于在服务器端查询该文件的唯一标识,例如,文件标识信息可以是文件路径、文件的MD5等。用户标识信息是用于验证用户身份的唯一标识,例如,用户标识信息可以是用户ID等。
查询模块103用于在缓存服务器中查询文件标识信息对应的锁定文件。第二获取模块104用于当查询模块103未查询到文件标识信息对应的锁定文件时,从文件服务器获取文件标识信息对应的第一原始文件。具体而言,查询模块103根据文件标识信息在缓存服务器中查询是否存在与文件标识信息对应的文件,其中,该文件在缓存服务器中是处于锁定状态的,即锁定文件。也就是说,在用户A请求访问文件时,并不直接从文件服务器获取文件,而是先在缓存服务器中查询是否存在已被锁定的文件,如果缓存服务器中不存在已被锁定的文件,则再从文件服务器获取该文件。如果查询模块103在缓存服务器中未查询到对应的锁定文件,则说明文件服务器上存储的原始文件目前处于未锁定的状态,用户A有权限从文件服务器上获取原始文件并对该原始文件加锁,因此,第 二获取模块104在文件服务器中根据文件标识信息查找到对应的原始文件,并获取该原始文件。
生成模块105用于根据第一用户标识信息和第一原始文件生成锁定文件。提交模块106用于将锁定文件提交至缓存服务器。具体而言,生成模块105将原始文件的文件内容展现给用户A,同时生成模块105根据用户A的用户标识信息锁定该原始文件,以生成包含原始文件和用户标识信息的锁定文件。然后,提交模块106以文件标识信息作为锁定文件的标识,将锁定文件提交至缓存服务器进行存储。
第二接收模块107用于接收针对第一原始文件的编辑操作,其中,提交模块106将编辑后的第一原始文件提交至缓存服务器,以使缓存服务器根据编辑后的第一原始文件对锁定文件进行更新。具体地,用户A可以对原始文件的文件内容进行编辑,当用户A选择保存编辑后的内容时,第二接收模块107接收用户的编辑操作,提交模块106将编辑后的原始文件加上用户标识信息提交至缓存服务器。也就是说,将用户A编辑后的内容保存至缓存服务器的锁定文件中。
本申请实施例的文件读写装置,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
图7是本申请一个具体实施例的文件读写装置的结构示意图,如图7所示,文件读写装置包括:第一接收模块101、第一获取模块102、查询模块103、第二获取模块104、生成模块105、提交模块106、第二接收模块107、第一判断模块108、第一提示模块109、第二判断模块110、更新模块111、第三接收模块112、解锁模块113、第四接收模块114、替换模块115和第二提示模块116。
具体地,第一判断模块108用于当查询模块103查询到文件标识信息对应的锁定文件时,判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配。第二获取模块104还用于当第一判断模块108判断第一用户标识信息与第二用户标识信息匹配时,从缓存服务器中获取锁定文件。具体地,如果查询模块103在缓存服务器中查询到对应的锁定文件,则说明文件服务器上存储的原始文件目前处于锁定的状态,则获取锁定文 件的用户标识信息,第一判断模块108判断用户A的用户标识信息和锁定文件的用户标识信息是否匹配,如果第一判断模块108判断用户A的用户标识信息和锁定文件的用户标识信息匹配,则用户A有权限获取锁定文件并进行编辑,因此,第二获取模块104从缓存服务器中获取锁定文件。
第一提示模块109用于当第一判断模块108判断第一用户标识信息与第二用户标识信息不匹配时,生成拒绝获取锁定文件的提示信息。具体地,如果是用户B访问缓存服务器中的锁定文件,则第一判断模块108判断用户B的用户标识信息和锁定文件的用户标识信息不匹配,即该锁定文件是用户A锁定的,则第一判断模块108判断用户B没有权限获取锁定文件进行编辑,第一提示模块109生成提示提示信息提示用户B。
在本申请的一个实施例中,文件读写装置还包括第二判断模块110和更新模块111。其中,第二获取模块104还用于从文件服务器获取第二原始文件。第二判断模块110用于判断缓存服务器中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配。提交模块106还用于当第二判断模块110判断第一提交信息与第二提交信息匹配时,将锁定文件提交至文件服务器,以使文件服务器将第二原始文件替换为锁定文件。具体地,提交模块106根据用户A编辑的内容对缓存服务器中的锁定文件更新后,第二获取模块104从文件服务器再次获取文件服务器中保存的原始文件,并从获取该原始文件的提交信息,如果第二判断模块110判断缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息匹配,则提交模块106将更新后的锁定文件异步提交至文件服务器,将文件服务器中的原始文件替换为更新后的锁定文件。
更新模块111用于当第二判断模块110判断第一提交信息与第二提交信息不匹配时,根据第二原始文件对锁定文件进行更新,并根据第二提交信息更新第一提交信息,其中,提交模块106还用于将更新后的锁定文件提交至文件服务器。具体地,如果第二判断模块110判断缓存服务器中锁定文件的提交信息和文件服务器中原始文件的提交信息不匹配,说明文件服务器中原始文件已经被更新,例如,用户通过文件服务器的客户端对原始文件进行了更新,则更新模块111将锁定文件的内容保存为副本,并获取原始文件的内容,根据原始文件的内容对锁定文件的内容进行更新。在用户A在解决锁定文件的内容和原始文件的内容之间的冲突之后,提交模块106将缓存服务器中的锁定文件的提交信息更新为文件服务器中原始文件的提交信息。然后,提交模块106将更新后的锁定文件异步提交至文件服务器,将文件服务器中的原始文件替换为更新后的锁定文件。
在本申请的一个实施例中,文件读写装置还包括第三接收模块112和解锁模块113。 其中,第三接收模块112用于接收针对缓存服务器中锁定文件的解锁请求。解锁模块113用于在第一判断模块108判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时,从缓存服务器中删除锁定文件。具体而言,具体地,在用户A对锁定文件编辑完成之后,用户A可以发送对锁定文件进行解锁的请求,第三接收模块112在接收到用户A发送的解锁请求后,提示用户即将对锁定文件解锁,并提示用户是否在解锁前将锁定文件提交至文件服务器中。在用户A确认对锁定文件解锁之后,第一判断模块108根据文件标识信息在缓存服务器中查找到对应的锁定文件,并判断锁定文件对应的用户标识信息是否和用户A的用户标识信息匹配。如果第一判断模块108判断锁定文件对应的用户标识信息和用户A的用户标识信息匹配,则解锁模块113从缓存服务器中删除该锁定文件。
在本申请的一个实施例中,文件读写装置还包括第四接收模块114、替换模块115和第二提示模块116。其中,第四接收模块114用于接收针对第二用户标识信息的替换请求。替换模块115用于根据替换请求将第二用户标识信息替换为第一用户标识信息。第二提示模块116用于生成第二用户标识信息被替换的提示信息。具体地,如果用户B没有权限获取锁定文件进行编辑,而用户B又急需对锁定文件进行编辑,此时该文件被用户A锁定,则用户B可以选择抢锁,直接将具有锁定文件的读写权限的用户A变为用户B具有权限。也就是说,用户B发送对缓存服务器中锁定文件所对应的用户标识信息的替换请求,第四接收模块114在接收到用户B发送的替换请求后,替换模块115将锁定文件的用户标识信息替换为用户B的用户标识信息,第二提示模块116生成锁定文件的用户标识信息被替换的提示信息以提示用户A。
本申请实施例的文件读写装置,为用户提供文件锁定、文件解锁和抢锁等功能,解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题,同时使用缓存服务器保存锁定文件可以解决多个WebIDE服务器中信息不同步的问题,使得多人协同开发时能够充分发挥快速、不受环境限制的优势。
为了实现上述实施例,本申请还提出一种文件读写系统。
图8是本申请一个实施例的文件读写装置的结构示意图,如图8所示,文件读写系统包括:WebIDE服务器1、缓存服务器2和文件服务器3。
具体地,WebIDE服务器1用于接收访问请求,并根据访问请求获取文件标识信息和第一用户标识信息,以及在缓存服务器2中查询文件标识信息对应的锁定文件,如果未查询到文件标识信息对应的锁定文件,则从文件服务器3获取文件标识信息对应的第 一原始文件,并根据第一用户标识信息和第一原始文件生成锁定文件,并将锁定文件提交至缓存服务器2,以及接收针对第一原始文件的编辑操作,并将编辑后的第一原始文件提交至缓存服务器2;以及
缓存服务器2用于存储锁定文件,并根据编辑后的第一原始文件对锁定文件进行更新。
在本申请的一个实施例中,WebIDE服务器1还用于当查询到文件标识信息对应的锁定文件时,判断第一用户标识信息是否与锁定文件对应的第二用户标识信息匹配,若第一用户标识信息与第二用户标识信息匹配,则从缓存服务器2中获取锁定文件。
在本申请的一个实施例中,WebIDE服务器1还用于当第一用户标识信息与第二用户标识信息不匹配时,生成拒绝获取锁定文件的提示信息。
在本申请的一个实施例中,文件服务器3存储有第二原始文件,其中第二原始文件为第一原始文件更新后的版本,WebIDE服务器1还用于从文件服务器3获取第二原始文件,并判断缓存服务器2中锁定文件的第一提交信息与第二原始文件的第二提交信息是否匹配,当第一提交信息与第二提交信息匹配时,将锁定文件提交至文件服务器3。文件服务器3还用于第二原始文件替换为锁定文件。
在本申请的一个实施例中,WebIDE服务器1还用于当第一提交信息与第二提交信息不匹配时,根据第二原始文件对锁定文件进行更新,并根据第二提交信息更新第一提交信息,以及将更新后的锁定文件提交至文件服务器3。文件服务器3还用于将第二原始文件替换为更新后的锁定文件。
在本申请的一个实施例中,WebIDE服务器1还用于接收针对缓存服务器2中锁定文件的解锁请求,并在判断第一用户标识信息与锁定文件对应的第二用户标识信息匹配时,从缓存服务器2中删除锁定文件。
在本申请的一个实施例中,WebIDE服务器1还用于接收针对第二用户标识信息的替换请求,并根据替换请求将第二用户标识信息替换为第一用户标识信息,以及生成第二用户标识信息被替换的提示信息。
另外,根据本申请实施例的文件读写系统实现方式以及作用可以参考上述实施例中文件读写方法和文件读写装置的实现方式,为了减少冗余,此处不做赘述。
本申请实施例的文件读写系统,通过缓存服务器实现了适用于WebIDE系统的文件锁定机制,利用缓存服务器作为文件服务器和WebIDE服务器之间缓冲,使用缓存机制实现文件的锁定,从而使得用户在对文件操作的过程中拥有文件的独享操作权,避免了 多个用户对同一个文件操作时提交的内容互相冲突,使得WebIDE系统能够在多个协作开发过程中发挥更大的作用。此外,使用缓存机制实现文件的锁定,比每次都修改文件服务器的数据库相比成本更低,且缓存机制能够更加灵活地处理多种文件、产生同一个文件的不同副本等等,给用户更好的体验。
进而,为用户提供文件锁定、文件解锁和抢锁等功能,解决了多人协同开发时提交的内容互相冲突、互相覆盖的问题,同时使用缓存服务器保存锁定文件可以解决多个WebIDE服务器中信息不同步的问题,使得多人协同开发时能够充分发挥快速、不受环境限制的优势。
应当理解,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本申请的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本申请的限制,本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (21)

  1. 一种文件读写方法,其特征在于,包括以下步骤:
    接收访问请求,并根据所述访问请求获取文件标识信息和第一用户标识信息;
    在缓存服务器中查询所述文件标识信息对应的锁定文件,如果未查询到所述文件标识信息对应的锁定文件,则从文件服务器获取所述文件标识信息对应的第一原始文件;
    根据所述第一用户标识信息和所述第一原始文件生成锁定文件,并将所述锁定文件提交至所述缓存服务器;以及
    接收针对所述第一原始文件的编辑操作,并将编辑后的第一原始文件提交至所述缓存服务器,以使所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。
  2. 如权利要求1所述的文件读写方法,其特征在于,在缓存服务器中查询所述文件标识信息对应的锁定文件之后,还包括:
    如果查询到所述文件标识信息对应的锁定文件,则判断所述第一用户标识信息是否与所述锁定文件对应的第二用户标识信息匹配,若所述第一用户标识信息与所述第二用户标识信息匹配,则从所述缓存服务器中获取所述锁定文件。
  3. 如权利要求2所述的文件读写方法,其特征在于,判断所述第一用户标识信息是否与所述锁定文件对应的第二用户标识信息匹配之后,还包括:
    若所述第一用户标识信息与所述第二用户标识信息不匹配,则生成拒绝获取所述锁定文件的提示信息。
  4. 如权利要求1所述的文件读写方法,其特征在于,所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新之后,还包括:
    从所述文件服务器获取第二原始文件,并判断所述缓存服务器中所述锁定文件的第一提交信息与所述第二原始文件的第二提交信息是否匹配,如果所述第一提交信息与所述第二提交信息匹配,则将所述锁定文件提交至所述文件服务器,以使所述文件服务器将所述第二原始文件替换为所述锁定文件。
  5. 如权利要求4所述的文件读写方法,其特征在于,判断所述锁定文件的第一提交信息与所述第二原始文件的第二提交信息是否匹配之后,还包括:
    如果所述第一提交信息与所述第二提交信息不匹配,则根据所述第二原始文件对所述锁定文件进行更新,并根据所述第二提交信息更新所述第一提交信息,以及将更新后的锁定文件提交至所述文件服务器。
  6. 如权利要求1或2所述的文件读写方法,其特征在于,还包括:
    接收针对所述缓存服务器中所述锁定文件的解锁请求,并在判断所述第一用户标识信息与所述锁定文件对应的第二用户标识信息匹配时,从所述缓存服务器中删除所述锁定文件。
  7. 如权利要求3所述的文件读写方法,其特征在于,生成拒绝获取所述锁定文件的提示信息之后,还包括:
    接收针对所述第二用户标识信息的替换请求,并根据所述替换请求将所述第二用户标识信息替换为第一用户标识信息,以及生成所述第二用户标识信息被替换的提示信息。
  8. 一种文件读写装置,其特征在于,包括:
    第一接收模块,用于接收访问请求;
    第一获取模块,用户根据所述访问请求获取文件标识信息和第一用户标识信息;
    查询模块,用于在缓存服务器中查询所述文件标识信息对应的锁定文件;
    第二获取模块,用于当所述查询模块未查询到所述文件标识信息对应的锁定文件时,从文件服务器获取所述文件标识信息对应的第一原始文件;
    生成模块,用于根据所述第一用户标识信息和所述第一原始文件生成锁定文件;
    提交模块,用于将所述锁定文件提交至所述缓存服务器;以及
    第二接收模块,用于接收针对所述第一原始文件的编辑操作,其中,所述提交模块将编辑后的第一原始文件提交至所述缓存服务器,以使所述缓存服务器根据所述编辑后的第一原始文件对所述锁定文件进行更新。
  9. 如权利要求8所述的文件读写装置,其特征在于,还包括:
    第一判断模块,用于当所述查询模块查询到所述文件标识信息对应的锁定文件时,判断所述第一用户标识信息是否与所述锁定文件对应的第二用户标识信息匹配;
    第二获取模块还用于当所述第一用户标识信息与所述第二用户标识信息匹配时,从所述缓存服务器中获取所述锁定文件。
  10. 如权利要求9所述的文件读写装置,其特征在于,还包括:
    第一提示模块,用于当所述第一用户标识信息与所述第二用户标识信息不匹配时,生成拒绝获取所述锁定文件的提示信息。
  11. 如权利要求8所述的文件读写装置,其特征在于,还包括:
    第二获取模块还用于从所述文件服务器获取第二原始文件;
    第二判断模块,用于判断所述缓存服务器中所述锁定文件的第一提交信息与所述第二原始文件的第二提交信息是否匹配;
    所述提交模块还用于当所述第二判断模块判断所述第一提交信息与所述第二提交信息匹配时,将所述锁定文件提交至所述文件服务器,以使所述文件服务器将所述第二原始文件替换为所述锁定文件。
  12. 如权利要求11所述的文件读写装置,其特征在于,还包括:
    更新模块,用于当所述第二判断模块判断所述第一提交信息与所述第二提交信息不匹配时,根据所述第二原始文件对所述锁定文件进行更新,并根据所述第二提交信息更新所述第一提交信息,其中,所述提交模块还用于将更新后的锁定文件提交至所述文件服务器。
  13. 如权利要求8或9所述的文件读写装置,其特征在于,还包括:
    第三接收模块,用于接收针对所述缓存服务器中所述锁定文件的解锁请求;
    解锁模块,用于在所述第一判断模块判断所述第一用户标识信息与所述锁定文件对应的第二用户标识信息匹配时,从所述缓存服务器中删除所述锁定文件。
  14. 如权利要求10所述的文件读写装置,其特征在于,还包括:
    第四接收模块,用于接收针对所述第二用户标识信息的替换请求;
    替换模块,用于根据所述替换请求将所述第二用户标识信息替换为第一用户标识信息;
    第二提示模块,用于生成所述第二用户标识信息被替换的提示信息。
  15. 一种文件读写系统,其特征在于,包括:WebIDE服务器、缓存服务器和文件服务器,其中,
    所述WebIDE服务器用于接收访问请求,并根据所述访问请求获取文件标识信息和第一用户标识信息,以及在缓存服务器中查询所述文件标识信息对应的锁定文件,如果未查询到所述文件标识信息对应的锁定文件,则从文件服务器获取所述文件标识信息对应的第一原始文件,并根据所述第一用户标识信息和所述第一原始文件生成锁定文件,并将所述锁定文件提交至所述缓存服务器,以及接收针对所述第一原始文件的编辑操作,并将编辑后的第一原始文件提交至所述缓存服务器;以及
    所述缓存服务器用于存储所述锁定文件,并根据所述编辑后的第一原始文件对所述锁定文件进行更新。
  16. 如权利要求15所述的文件读写系统,其特征在于,
    所述WebIDE服务器还用于当查询到所述文件标识信息对应的锁定文件时,判断所述第一用户标识信息是否与所述锁定文件对应的第二用户标识信息匹配,若所述第一用户标识信息与所述第二用户标识信息匹配,则从所述缓存服务器中获取所述锁定文件。
  17. 如权利要求16所述的文件读写系统,其特征在于,
    所述WebIDE服务器还用于当所述第一用户标识信息与所述第二用户标识信息不匹配时,生成拒绝获取所述锁定文件的提示信息。
  18. 如权利要求15所述的文件读写系统,其特征在于,所述文件服务器存储有所述第二原始文件,其中所述第二原始文件为所述第一原始文件更新后的版本,
    所述WebIDE服务器还用于从所述文件服务器获取第二原始文件,并判断所述缓存服务器中所述锁定文件的第一提交信息与所述第二原始文件的第二提交信息是否匹配,当所述第一提交信息与所述第二提交信息匹配时,将所述锁定文件提交至所述文件服务器;
    所述文件服务器还用于所述第二原始文件替换为所述锁定文件。
  19. 如权利要求18所述的文件读写系统,其特征在于,
    所述WebIDE服务器还用于当所述第一提交信息与所述第二提交信息不匹配时,根据所述第二原始文件对所述锁定文件进行更新,并根据所述第二提交信息更新所述第一提交信息,以及将更新后的锁定文件提交至所述文件服务器;
    所述文件服务器还用于将所述第二原始文件替换为更新后的锁定文件。
  20. 如权利要求15或16所述的文件读写系统,其特征在于,
    所述WebIDE服务器还用于接收针对所述缓存服务器中所述锁定文件的解锁请求,并在判断所述第一用户标识信息与所述锁定文件对应的第二用户标识信息匹配时,从所述缓存服务器中删除所述锁定文件。
  21. 如权利要求17所述的文件读写系统,其特征在于,
    所述WebIDE服务器还用于接收针对所述第二用户标识信息的替换请求,并根据所述替换请求将所述第二用户标识信息替换为第一用户标识信息,以及生成所述第二用户标识信息被替换的提示信息。
PCT/CN2016/093493 2015-08-14 2016-08-05 文件读写方法、装置和系统 WO2017028688A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/895,927 US10338917B2 (en) 2015-08-14 2018-02-13 Method, apparatus, and system for reading and writing files

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510500501.0 2015-08-14
CN201510500501.0A CN106469150B (zh) 2015-08-14 2015-08-14 文件读写方法、装置和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/895,927 Continuation US10338917B2 (en) 2015-08-14 2018-02-13 Method, apparatus, and system for reading and writing files

Publications (1)

Publication Number Publication Date
WO2017028688A1 true WO2017028688A1 (zh) 2017-02-23

Family

ID=58051976

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/093493 WO2017028688A1 (zh) 2015-08-14 2016-08-05 文件读写方法、装置和系统

Country Status (3)

Country Link
US (1) US10338917B2 (zh)
CN (1) CN106469150B (zh)
WO (1) WO2017028688A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107665235A (zh) * 2017-07-27 2018-02-06 上海壹账通金融科技有限公司 缓存处理方法、装置、计算机设备和存储介质
CN109918356A (zh) * 2019-03-15 2019-06-21 深信服科技股份有限公司 文件读取方法、装置、设备及计算机可读存储介质
CN112905533A (zh) * 2021-02-05 2021-06-04 优车库网络科技发展(深圳)有限公司 文件提交的管理方法、装置、设备及存储介质
CN114238232A (zh) * 2021-12-15 2022-03-25 南方电网电力科技股份有限公司 一种智能电表文件读写系统、方法、设备和介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107016047A (zh) * 2017-02-20 2017-08-04 阿里巴巴集团控股有限公司 文档查询、文档存储方法及装置
CN110019057B (zh) * 2017-09-27 2021-10-22 华为技术有限公司 请求处理方法及装置
CN111327658B (zh) * 2018-12-14 2022-12-09 中国移动通信集团山东有限公司 冲突式人机命令交互通道并行工作控制方法及装置
CN110716900A (zh) * 2019-10-10 2020-01-21 支付宝(杭州)信息技术有限公司 一种数据查询方法和系统
CN111125053A (zh) * 2019-10-31 2020-05-08 苏州浪潮智能科技有限公司 一种优化数据库写入速率的方法和设备
CN111158645B (zh) 2019-12-10 2022-09-20 杭州中天微系统有限公司 提供集成开发环境的系统和方法
CN111475476A (zh) * 2020-03-08 2020-07-31 苏州浪潮智能科技有限公司 一种基于svn避免多人等待文件解锁的方法及装置
CN111666045A (zh) * 2020-05-15 2020-09-15 深圳市大富网络技术有限公司 基于Git系统的数据处理方法、系统、设备及存储介质
CN112667224A (zh) * 2021-01-12 2021-04-16 北京字节跳动网络技术有限公司 一种文件处理方法、装置、计算机设备及存储介质
CN113590560A (zh) * 2021-06-29 2021-11-02 济南浪潮数据技术有限公司 一种分布式系统的缓存优化方法、系统、设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615373A (en) * 1993-08-26 1997-03-25 International Business Machines Corporation Data lock management in a distributed file server system determines variable lock lifetime in response to request to access data object
CN102193959A (zh) * 2010-03-11 2011-09-21 株式会社日立制作所 计算机系统以及缓存控制方法
US20120265836A1 (en) * 2011-04-15 2012-10-18 Hitachi, Ltd. File sharing system and file sharing method
CN103345482A (zh) * 2013-06-20 2013-10-09 上海爱数软件有限公司 一种网络存储系统及其文件访问冲突处理方法
CN104331428A (zh) * 2014-10-20 2015-02-04 暨南大学 一种小文件和大文件的存储及访问方法
CN104376122A (zh) * 2014-12-08 2015-02-25 浪潮通用软件有限公司 浏览器客户端获得静态文件的方法及服务器

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002313583A1 (en) * 2001-08-01 2003-02-17 Actona Technologies Ltd. Virtual file-sharing network
US7730321B2 (en) * 2003-05-09 2010-06-01 Emc Corporation System and method for authentication of users and communications received from computer systems
US8041735B1 (en) * 2002-11-01 2011-10-18 Bluearc Uk Limited Distributed file system and method
US8121061B2 (en) * 2008-06-26 2012-02-21 Microsoft Corporation Efficient file management through granular opportunistic locking
US8930686B2 (en) * 2009-12-23 2015-01-06 International Business Machines Corporation Deduplication of encrypted data
US8260816B1 (en) * 2010-05-20 2012-09-04 Vmware, Inc. Providing limited access to a file system on shared storage
US20130074158A1 (en) * 2011-09-20 2013-03-21 Nokia Corporation Method and apparatus for domain-based data security
US9575986B2 (en) * 2012-04-30 2017-02-21 Synopsys, Inc. Method for managing design files shared by multiple users and system thereof
US8943031B2 (en) * 2012-08-20 2015-01-27 Red Hat, Inc. Granular self-healing of a file in a distributed file system
US9473506B1 (en) * 2013-10-15 2016-10-18 Progress Software Corporation Secure file transfer and notification server
US9569459B1 (en) * 2014-03-31 2017-02-14 Amazon Technologies, Inc. Conditional writes at distributed storage services
US10169367B2 (en) * 2014-06-06 2019-01-01 Panzura, Inc. Managing opportunistic locks in a distributed file system
US9697227B2 (en) * 2014-10-27 2017-07-04 Cohesity, Inc. Concurrent access and transactions in a distributed file system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615373A (en) * 1993-08-26 1997-03-25 International Business Machines Corporation Data lock management in a distributed file server system determines variable lock lifetime in response to request to access data object
CN102193959A (zh) * 2010-03-11 2011-09-21 株式会社日立制作所 计算机系统以及缓存控制方法
US20120265836A1 (en) * 2011-04-15 2012-10-18 Hitachi, Ltd. File sharing system and file sharing method
CN103345482A (zh) * 2013-06-20 2013-10-09 上海爱数软件有限公司 一种网络存储系统及其文件访问冲突处理方法
CN104331428A (zh) * 2014-10-20 2015-02-04 暨南大学 一种小文件和大文件的存储及访问方法
CN104376122A (zh) * 2014-12-08 2015-02-25 浪潮通用软件有限公司 浏览器客户端获得静态文件的方法及服务器

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107665235A (zh) * 2017-07-27 2018-02-06 上海壹账通金融科技有限公司 缓存处理方法、装置、计算机设备和存储介质
CN107665235B (zh) * 2017-07-27 2020-06-30 深圳壹账通智能科技有限公司 缓存处理方法、装置、计算机设备和存储介质
CN109918356A (zh) * 2019-03-15 2019-06-21 深信服科技股份有限公司 文件读取方法、装置、设备及计算机可读存储介质
CN109918356B (zh) * 2019-03-15 2023-05-12 深信服科技股份有限公司 文件读取方法、装置、设备及计算机可读存储介质
CN112905533A (zh) * 2021-02-05 2021-06-04 优车库网络科技发展(深圳)有限公司 文件提交的管理方法、装置、设备及存储介质
CN114238232A (zh) * 2021-12-15 2022-03-25 南方电网电力科技股份有限公司 一种智能电表文件读写系统、方法、设备和介质
CN114238232B (zh) * 2021-12-15 2024-04-02 南方电网电力科技股份有限公司 一种智能电表文件读写系统、方法、设备和介质

Also Published As

Publication number Publication date
CN106469150A (zh) 2017-03-01
US20180173521A1 (en) 2018-06-21
CN106469150B (zh) 2019-10-08
US10338917B2 (en) 2019-07-02

Similar Documents

Publication Publication Date Title
WO2017028688A1 (zh) 文件读写方法、装置和系统
US11755616B2 (en) Synchronized organization directory with team member folders
CN108932282B (zh) 一种数据库迁移方法、装置和存储介质
US9977811B2 (en) Presenting availability statuses of synchronized objects
KR101647535B1 (ko) 교차 채널 공동 저작 일관성 제공 기법
US20070214195A1 (en) Idempotent journal mechanism for file system
TW201828100A (zh) 檔案讀寫方法、裝置和系統
JP2009157699A (ja) ファイル排他制御システム及びファイル排他制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16836552

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16836552

Country of ref document: EP

Kind code of ref document: A1