CN113672966A - File access control method and system - Google Patents

File access control method and system Download PDF

Info

Publication number
CN113672966A
CN113672966A CN202010404031.9A CN202010404031A CN113672966A CN 113672966 A CN113672966 A CN 113672966A CN 202010404031 A CN202010404031 A CN 202010404031A CN 113672966 A CN113672966 A CN 113672966A
Authority
CN
China
Prior art keywords
file
target file
target
condition
access
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202010404031.9A
Other languages
Chinese (zh)
Inventor
张定平
王府
韩竹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Yijing Network Technology Co ltd
Original Assignee
Shanghai Yicun Network Technology Co ltd
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 Shanghai Yicun Network Technology Co ltd filed Critical Shanghai Yicun Network Technology Co ltd
Priority to CN202010404031.9A priority Critical patent/CN113672966A/en
Publication of CN113672966A publication Critical patent/CN113672966A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/604Tools and structures for managing or administering access control systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Automation & Control Theory (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application relates to a file access control method and a system, which comprises a relay lock service detection module, a relay lock logic module and an access interception module, wherein when the access operation of a target file is monitored, the locking state and the exclusive condition of the target file are obtained, and whether the target file is allowed to be accessed or not is judged according to the locking state and the exclusive condition; intercepting or releasing the access operation of the target file according to the judgment result of the relay lock logic module; when the locked state is unlocked and the exclusive condition is satisfied, access to the target file is permitted. The file access control method and system provided by the application realize exclusive access of the file through a relay locking mechanism in a wide area network environment, and are particularly used for ensuring strong consistency of the file when a plurality of persons edit the same file in a plurality of regions at the same time.

Description

File access control method and system
Technical Field
The present application relates to the field of computers and the internet, and in particular, to a method and a system for controlling file sharing access.
Background
With the development of network technology and the popularity of online office, multiple parties and multiple regions are often required to share or operate the same file through a network, and a corresponding sharing and operating mechanism is required to avoid errors or confusion.
There are two main current schemes for sharing the same file among multiple parties:
the first is to store the file in a server, and each user remotely accesses the same original file. However, this solution has a high requirement on network conditions, and for the cases of poor network conditions (e.g., slow network speed for uploading and downloading) or too large files, the performance of accessing through the network is poor compared with accessing local files.
The second is to distribute copies of the file to computers local to the users, and then to ensure consistency of the copies of the file in each region by means of synchronization. The synchronization mode can be automatic synchronization through network or software, for example, automatically detecting the change of the file through a program, and uploading or downloading the latest version of the file. The synchronization mode can also be manual synchronization, for example: using a usb disk, a copy on a removable hard disk, using instant messaging software, mail sending, etc.
With the second scheme, when multiple users edit the same file at multiple terminals, editing conflicts may occur, such as: two people modify the same part of the same file at the same time, so that it becomes a problem to keep the change of which party when synchronously merging. To solve such problems, one way is to lock the file, i.e. when the user opens the file, the file is locked, and the users at other ends are not allowed to change other copies of the file, i.e. the file is monopolized by the locker; when the locker closes the file, unlocking is carried out again to allow the next editor to monopolize the file.
Disclosure of Invention
After long-term observation and experiments, the inventor finds that the existing file lock technology has the following disadvantages because the opening and closing events of a single file are used as the trigger conditions for locking and unlocking:
(1) when a user opens a file, there is no guarantee that the version of the file at that time is up-to-date. If the user edits based on a file that is not the latest version, the result of this edit may conflict with the latest version stored by the server.
(2) A close event of a file is not a sufficient condition for unlocking. When the file is closed, although the current user is indicated to have finished editing, it does not mean that the file has been synchronized, i.e. it cannot be ensured that the locally updated content can be obtained by the user at the other end in time, which will result in that the user at the other end is not based on the latest version of the file when editing, in which case there will be a possibility of generating a conflicting file.
(3) There is no concept of "file clusters". The existing file locking mechanism can only operate a single file, and can not bind a plurality of files together and perform unified operation as the same file. Some software provides a file model, which is a "file cluster" consisting of a "main file" and several "auxiliary files (folders)," the contents of these files are related, and when the content of one of the files changes, the contents of other files may also change accordingly. Such as: the center Model (Central Model) provided by Autodesk Revit software is composed of an × rvt file and an × dat file under a × backup folder. There is also a potential for conflicting files to be created if these files are not uniformly locked and synchronized, such as: the main file is not unlocked and the dependent files have been updated and synchronized.
In summary, the existing file locking mechanism cannot reliably prevent the generation of conflicting files.
In view of the above disadvantages of the prior art, the inventors have conducted long-term research and analysis to creatively propose the following ideas to solve the technical problems existing in the prior art:
(1) before opening a file, it is necessary to ensure that this file is a "continued editable" file that is secure and reliable, without risk of file conflicts.
And intercepting the access operation of a user to the file by adopting a driver or a file system realized by the driver or the file system, so as to prevent the access request when the file does not meet 'continuously editable'. Adding an 'exclusive condition' concept, checking whether the file meets the 'exclusive condition' before the operation of accessing the file is allowed, and if so, allowing the operation; if not, the operation is prevented.
(2) And supplementing the unlocking condition of the file to ensure that the user at the other end can acquire the 'continuously editable' version of the file after the file is marked as unlocked.
Upon detecting a file close, instead of unlocking immediately, the server is updated with relevant information about this file, such as: synchronize the entire file, update the "exclusive condition" required by the next locker, etc.
(3) It is necessary to bind a plurality of files and/or folders together as a whole for synchronization, locking, unlocking and other operations, which is beneficial to the file model provided by software such as Autodesk review and the like. A plurality of files associated with each other can be grouped into the same structure or object (file cluster), and for the files in the same file cluster, the files can be synchronized together when all the files in the file cluster are ready (for example, all the files are in an Unlock state), but not when a single file is updated, the file is immediately synchronized, so that a conflict is generated when other files are not ready, and the problem that the conflict is generated because the plurality of associated files are not integrally or consistently synchronized can be effectively solved.
The concept of' file clusters is introduced, the association relation of the file clusters is stored in a data structure of software, and when certain file is operated, other files associated with the certain file are also operated correspondingly.
In view of the foregoing defects in the prior art, the present application provides a file access control method and system, which implement exclusive access to a file through a relay lock mechanism in a wide area network environment, and are particularly used to ensure strong consistency of files when multiple persons edit the same file simultaneously in multiple regions.
The 'relay' second word of the power lock is derived from the fact that the Nth user can monopolize the file only after the monopolizing condition given by the N-1 st user is met. The "exclusive condition" may be a direct or indirect condition, and is intended to ensure that the content of the local file copy completely coincides with the result of the N-1 th edition before the nth edition, and all conditions that can achieve this purpose may be referred to as "exclusive conditions". Wherein the direct condition and the indirect condition may be:
(1) direct conditions: the file characteristic value information stored by the server is directly used for checking the local file, such as: file version number, file Hash value, file last modification time and the like;
(2) indirect conditions: the server does not directly store the verification condition of the file, but stores the acquisition mode of the condition. For example: in the scenario of P2P or accelerated synchronization of lan, the exclusive condition may be the communication mode (e.g. IP address) of the last locker, and the next visitor will directly communicate with the last locker to obtain the characteristic value of the local file of the last locker for verification, and when the characteristic values are inconsistent, the latest version of the file may be pulled from the last locker directly in the mode of P2P.
A "file cluster" is a grouping of multiple files and/or folders together so that they can be manipulated as a single file.
When a user operates a file locally, whether the local file is a file which can be continuously edited is judged. The file which can be continuously edited means that a user edits based on the file of the version, so that the file can not generate conflict in the subsequent process, and one file can be continuously edited when two conditions are met:
(1) the file is in an Unlocked (Unlocked) state;
(2) the file meets the exclusive condition, namely before the N edition, the content of the file is consistent with the result of the N-1 edition.
Correspondingly, if the file is in a Locked (Locked) state or the file does not satisfy the "exclusive condition", it may be considered that the file is not a "continuously editable" file, i.e., there is a possibility that a conflict may occur in continuously editing the file.
It should be noted that, multiple parties share, synchronize and edit the same file, local versions of the file are stored in local operating systems or memories of the parties, an online version of the file is also stored in a server (or called an online platform or a cloud), and through a sharing and synchronizing mechanism, the contents of the local versions and the online version of the file are stored to be consistent. Thus, in this application, the local version and the online version of the file are collectively referred to as the file by default, i.e., any one or more of the local version and the online version of the file may be included, unless explicitly indicated or distinguished. In addition, unless otherwise indicated, the local operation of a file in this application refers to various operations such as opening, viewing, editing, saving, transmitting, marking, and the like, of a local version of the file stored at the client (or referred to as a device or a user device); similarly, the online operation of the file in the present application refers to various operations such as opening, viewing, editing, saving, transmitting, and marking the online version of the file stored in the server.
In one aspect, the present application provides a file access control method, including: when monitoring the access operation of the target file, acquiring the locking state and the exclusive condition of the target file; judging whether the target file is allowed to be accessed or not according to the locking state and the exclusive condition; wherein if the locked state is unlocked and the exclusive condition is satisfied, allowing access to the target file.
In some embodiments, optionally, the lock status is determined first, and then the exclusive condition is determined; if the locking state is locked, the target file is not allowed to be accessed; and/or disallowing access to the target file if the locked state is non-locked but does not satisfy the exclusive condition.
In some embodiments, optionally, the target file, and other files associated with the target file, form a file cluster based on the association relationship, wherein the form of the target file and other files comprises files or folders; and other files in the file cluster, and the other files have the same locking state and exclusive condition with the target file; and when the target file is operated, performing corresponding operation on other files in the file cluster according to the association relation.
In some embodiments, optionally, according to the information included in the exclusive condition, it is determined whether the current content of the target file is consistent with the content of the target file saved last time, so as to determine whether the exclusive condition is satisfied.
In some embodiments, optionally, the exclusive condition includes a direct condition, where the direct condition is configured to be information that can be directly used to determine whether the current content of the target file is consistent with the content of the target file saved last time; and/or the exclusive condition includes an indirect condition configured to be usable for acquiring the direct condition.
In some embodiments, optionally, the exclusive condition includes one or more of the following information: the version number of the file; a hash value of the file; the previous modification time of the file; a characteristic value of the file; the communication mode of the previous visitor of the file; and obtaining the last saved version of the file.
In some embodiments, optionally, the direct condition comprises a version number of the file; comparing the version number of the target file with the version number in the exclusive condition; if the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file; if the version number of the target file is smaller than the version number in the exclusive condition, judging that the target file needs to be updated; and if the version number of the target file is greater than the version number in the exclusive condition, judging that an error occurs.
In some embodiments, optionally, the indirect condition includes a communication manner of a previous visitor, and the previous visitor communicates with the previous visitor according to the communication manner of the previous visitor in the exclusive condition to obtain a direct condition for comparing whether the current content of the target file is consistent with the previously saved content of the target file from the previous visitor; and/or the indirect condition comprises an acquisition mode of the previous saved version, and the previous saved version is acquired according to the acquisition mode of the previous saved version in the exclusive condition so as to update the target file.
In some embodiments, optionally, after the target file is accessed, the pre-unlocking operation is completed, the exclusive condition is updated, and the locking state is modified to be non-locking.
In some embodiments, optionally, the pre-unlocking operation includes one or more of: closing the target file; saving the target file; uploading the stored target file to a server; uploading a folder associated with the target file to a server; and carrying out corresponding operation on the file cluster to which the target file belongs and other files included in the file cluster.
In another aspect, the present application further provides a file access control system, including a client, where the client includes: the relay lock logic module is configured to acquire a locking state and an exclusive condition of the target file when monitoring an access operation on the target file, and judge whether to allow the target file to be accessed according to the locking state and the exclusive condition; the access intercepting module is configured to intercept or release the access operation on the target file according to the judgment result of the relay lock logic module; wherein the baton lock logic module is further configured to allow access to the target file when the locked state is unlocked and the exclusive condition is satisfied.
In some embodiments, optionally, the client further includes: the relay lock service detection module is configured to detect whether the relay lock logic module operates normally; and/or an access monitoring module configured to monitor an access operation to the target file.
In some embodiments, optionally, the method further includes: a server configured to be able to save a lock state and an exclusive condition of a target file; the power lock logic module is in communication connection with the server and is configured to be capable of obtaining the locked state and the exclusive condition of the target file from the server.
In some embodiments, optionally, the baton lock logic module is further configured to determine the lock status first, and then determine the exclusive condition; if the locking state is locked, the target file is not allowed to be accessed; and/or disallowing access to the target file if the locked state is non-locked but does not satisfy the exclusive condition.
In some embodiments, optionally, the target files, as well as other files associated with the target files, form a cluster of files based on the incidence relationships; the target file and other file forms comprise files or folders; and other files in the file cluster, and the other files have the same locking state and exclusive condition with the target file; and the client is configured to be capable of performing corresponding operations on other files in the file cluster according to the association relation when the target file is operated.
In some embodiments, optionally, the baton lock logic module is further configured to determine whether the current content of the target file is consistent with the content of the target file saved last time according to information included in the exclusive condition, so as to determine whether the exclusive condition is met; wherein the exclusive condition includes one or more of the following information: the version number of the file; a hash value of the file; the previous modification time of the file; a characteristic value of the file; the communication mode of the previous visitor of the file; and obtaining the last saved version of the file.
In some embodiments, optionally, the baton lock logic module is further configured to compare the version number of the target file with the version number in the exclusive condition, and determine whether the current content of the target file is consistent with the previously saved content of the target file; if the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file; if the version number of the target file is smaller than the version number in the exclusive condition, judging that the target file needs to be updated; and if the version number of the target file is greater than the version number in the exclusive condition, judging that an error occurs.
In some embodiments, optionally, the baton lock logic module is further configured to communicate with the previous visitor according to a communication manner of the previous visitor in the exclusive condition, so as to compare whether the current content of the target file is consistent with the content of the target file saved last time; and/or the relay lock logic module is further configured to acquire the previous saved version according to the acquisition mode of the previous saved version in the exclusive condition so as to update the target file.
In some embodiments, optionally, the client is further configured to complete the pre-unlocking operation after accessing the target file, update the exclusive condition, and modify the locked state to be unlocked; wherein the pre-unlocking operation comprises one or more of the following operations: closing the target file; saving the target file; uploading the stored target file to a server; and uploading the folder associated with the target file to the server.
On the other hand, the present application also provides a file access control method, including: when monitoring access operation on target files, inquiring whether the target files are contained in a file cluster, wherein the form of the target files comprises files or folders; and if the target file is contained in the file cluster, determining whether to allow an access operation to the target file according to the state of the file cluster.
In some embodiments, optionally, the method further includes: if access operations to target files are permitted, the file clusters and/or other files contained in the file clusters are processed accordingly, wherein the other files are in the form of files or folders.
In some embodiments, optionally, the file cluster comprises a file list comprising file identifications corresponding to each file in the file cluster; and querying whether a target file is included in the file cluster by retrieving the file list.
In some embodiments, optionally, the target files are included in a file cluster if the file identification of the target file is included in a file list, or the target file is subordinate to a folder in a file list.
In some embodiments, the status of file clusters optionally includes one or more of the following: is locked; unlocking; the reading is carried out; can be written; can be deleted; monopolizing; its children can be manipulated.
In some embodiments, optionally, the state of a file cluster is a minimum permission state for all files in the file cluster.
In some embodiments, optionally, the access operation comprises one or more of: reading; writing; deleting; adding a file; subfolders are added.
In some embodiments, optionally, if the status of a file cluster is locked, then no access operations to the target file are permitted.
In some embodiments, optionally, if the status of a file cluster is unlocked and the access operation is delete, then the access operation to the target file is allowed and the target file is removed from the file cluster.
In another aspect, the present application further provides a file access control system, including: the file cluster system comprises a file cluster module, wherein the file cluster module comprises a file list, the file list comprises file identifications corresponding to each file in the file cluster, and each file in the file cluster comprises a file or a file folder in a form.
In some embodiments, optionally, the method further includes: the access monitoring module is configured to monitor and control access operation on the target file; the access monitoring module is further configured to be capable of inquiring the file cluster module whether a target file is contained in the file cluster when an access operation on the target file is monitored, wherein the target file comprises a file or a folder in a form; the file cluster module is further configured to inquire whether target files are contained in the file clusters, wherein if the target files are contained in the file clusters, the state of the file clusters is fed back to the access monitoring module; the access monitoring module is further configured to determine whether to allow an access operation to a target file based on the status of the file clusters.
In some embodiments, optionally, the method further includes: and the association operation module is configured to be capable of correspondingly processing the file clusters and/or other files contained in the file clusters when access operation to the target files is allowed, wherein the other files comprise files or folders in forms.
In some embodiments, optionally, the access monitoring module is further configured to be able to query whether target files are contained in a file cluster by retrieving a list of files.
In some embodiments, optionally, the target files are included in a file cluster if the file identification of the target file is included in a file list, or the target file is subordinate to a folder in a file list.
In some embodiments, the status of file clusters optionally includes one or more of the following: is locked; unlocking; the reading is carried out; can be written; can be deleted; monopolizing; its children can be manipulated.
In some embodiments, optionally, the state of a file cluster is a minimum permission state for all files in the file cluster.
In some embodiments, optionally, the access operation comprises one or more of: reading; writing; deleting; adding a file; subfolders are added.
In some embodiments, optionally, the access monitoring module is further configured to disallow access operations to the target file when the status of a file cluster is locked.
In some embodiments, optionally, when the status of a file cluster is unlocked and the access operation is delete, the access monitoring module is further configured to enable the access operation to the target file; and the association operation module is further configured to enable removal of the target files from the file clusters.
In another aspect, the present application further provides a file access control device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor is configured to be capable of implementing the steps of the file access control method according to the above when executing the computer program.
In another aspect, the present application also provides a computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, is capable of implementing the steps of the file access control method according to the above.
Compared with the existing file locking mechanism, the method and the system provided by the application have at least the following advantages:
(1) the file system which is driven or realized by the file system per se intercepts the opening event of the file by the user, and adds the judgment of 'exclusive condition' during locking, thereby effectively preventing an editor from opening the file which does not meet the 'continuously editing' condition and preventing the conflict.
(2) After the file is closed, unlocking is carried out after the unlocking prerequisite condition is executed, and the possibility that other users can obtain the file which can be continuously edited in the point (1) is provided.
(3) The concept of "file clusters" extends the support of file locks from a single file to multiple files and/or folders.
Compared with the prior art, the file access control method and the file access control system can ensure the consistency of the files under the condition that the existing file locking mode cannot be used for detecting or avoiding file conflict, thereby obviously reducing the occurrence of file conflict and enhancing the consistency of shared files.
The conception, specific structure and technical effects of the present application will be further described in conjunction with the accompanying drawings to fully understand the purpose, characteristics and effects of the present application.
Drawings
The present application will become more readily understood from the following detailed description when read in conjunction with the accompanying drawings, wherein like reference numerals designate like parts throughout the figures, and in which:
fig. 1 is a schematic structural diagram of an embodiment of a file access control system in the present application.
Fig. 2 is a block diagram of an embodiment of a client according to the present application.
Fig. 3 is a block diagram of an embodiment of a server according to the present application.
Fig. 4 is a schematic architecture diagram of an embodiment of a file access control system in the present application.
Fig. 5 is a schematic diagram of file state transition of an embodiment of a file access control method in the present application.
Fig. 6 is a flowchart illustrating an embodiment of a file access control method according to the present application.
FIG. 7 is a block diagram of an embodiment of a file access control system according to the present application.
FIG. 8 is a schematic block diagram of one embodiment of a computer apparatus, device or terminal according to the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The present application may be embodied in many different forms of embodiments and the scope of the present application is not limited to only the embodiments set forth herein. All other embodiments that can be derived by a person skilled in the art from the embodiments given herein without making any creative effort shall fall within the protection scope of the present application.
Various embodiments of the present application will now be described with reference to the accompanying drawings, which form a part hereof. It should be understood that although directional terms, such as "front," "back," "upper," "lower," "left," "right," "inner," "outer," "top," "bottom," "front," "back," "proximal," "distal," "transverse," "longitudinal," "width," "length," "height," "axial," "radial," "clockwise," "counterclockwise," and the like may be used in this application to describe various example features and elements of the application, these terms are used herein for convenience of description only and are to be construed as being based on the example orientations shown in the figures. The embodiments disclosed herein may be arranged in different orientations and the directional terminology is used for purposes of illustration and is in no way intended to be limiting.
For convenience of description, the connection relationships between the respective modules or portions shown in the drawings are only exemplary descriptions, and those skilled in the art can fully adopt other equivalent connection relationships as long as the functions of the technical solutions of the present application can be achieved by the respective modules or portions in such connection relationships. The embodiments disclosed in this application can be arranged in different equivalent connection relationships, so the connection relationships shown in the drawings and the relevant contents of the description are only used as illustrations and should not be regarded as limitations.
The dimensions of each of the elements shown in the figures are arbitrarily illustrated and the application does not define the specific dimensions of each element unless explicitly stated or described in the specification or drawings. In order to make the illustration clearer, the dimensions of components are exaggerated or the corresponding proportional relationships are adjusted appropriately in some places in the drawings.
Ordinal terms such as "first" and "second" are used herein only for distinguishing and identifying, and do not have any other meanings, unless otherwise specified, either by indicating a particular sequence or by indicating a particular relationship. For example, the term "first component" does not itself imply the presence of a "second component", nor does the term "second component" itself imply the presence of a "first component".
Fig. 1 is a schematic structural diagram of an embodiment of a file access control system in the present application. As shown in fig. 1, the system includes clients (or terminals, devices, apparatuses, entities) 100A, 100B, 100C (collectively referred to as clients 100), a server (also referred to as online platform, cloud, server) 110 and a network 120. Three clients are shown here for illustrative purposes, and the system may include virtually any number of clients. Similarly, other modules or components described and illustrated in this application may also comprise single or multiple instances, as appropriate to the embodiment, and without loss of generality.
The client 100 may be any suitable computer client, handheld mobile client, tablet computer, or other computing device for locally storing, viewing, editing, and synchronizing files with the server 110 and other clients 100.
Each client 100 communicates with a server 110 over a network 120. Network 120 may be any suitable network and may include, for example, a local area network, a wide area network, a private network, a global network, and any combination thereof. In some embodiments, the client 100 communicates with a local network service provider via a wired or wireless communication network and communicates with the server 110 over the internet. Clients 100A, 100B, and 100C may communicate among each other through the intermediary of server 110, or may communicate directly with each other through network 120 or other communication network (as shown in phantom in FIG. 1), such as via a point-to-point (P2P) communication, a Bluetooth (Bluetooth) connection, or a wired connection via a Universal Serial Bus (USB).
The server 110 provides file sharing and synchronization services for users of the client 100, such as allowing a user of the client 100A to share the same file with users of other clients 100B, 100C. The server 110 may also update in response to changes in the content of the shared file and allow for synchronous updates of the shared file across multiple clients 100. For example: the file at the clients 100B, 100C and the server 110 is updated to the final (or latest, most recent, last) version of the file saved at the client 100A, based on the local modifications to the file at the client 100A. Similarly, the file at the client 100A, 100B, 100C may also be updated to the final version of the file maintained at the server 110 based on online modifications to the file at the server 110.
In some embodiments, the same user may synchronize files among multiple clients 100 associated with the user's account, and the user may also share and synchronize files among clients 100 associated with other users' accounts.
The content stored by the client 100 and the server 110 may include any type or format of data or content stored in a digital form, such as digital data, documents, multimedia (e.g., image, photo, video, audio, streaming media, etc.), data files, databases, source code, object code, records, and any other type of data, files or folders, which may be collectively referred to as files or content items, and the form and type of storage or presentation may be files or folders, if not specifically indicated below. In some operating systems, files (files) and folders (Directory) are collectively referred to as File System items (File System Entries), and in this application, files or content items are collectively referred to as files or content items, unless otherwise specified. The files stored by server 110 may also be used to organize other files or content items, such as folders, tables, collections, albums, playlists, or for other database structures (e.g., object oriented, keys, values, etc.). In practice, various clients 100 may synchronize different sets of files based on account associations and corresponding permissions, etc.
Fig. 2 is a block diagram of an embodiment of the client 100 according to the present application. As shown in FIG. 2, client 100 includes an operating system 210, a local file collaboration program 240, and one or more local application programs 220. The local applications 220 may include various applications for creating, viewing, using, and modifying files stored on the client 100, such as word processors, spreadsheets, database management systems, code editors, image or video editors, e-book readers, audio or video players, and so forth. The local file cooperation program 240 may be used independently or in cooperation with the operating system 210, the local application 220, and the like, for performing operations and processes of sharing, synchronizing, monitoring, cooperating, and the like of the local file of the client 100, so as to execute and implement various file access control methods provided by the present application. The operating system 210 on each client 100 provides a local file management system and may run various software modules, such as local applications 220, local file collaboration programs 240.
The client 100 may also include a display for providing information to the user, and in some clients 100 include a touch screen. Client 100 may also include a network interface for communicating with server 110 via network 120. The client 100 may also include a user input module that may receive user input from various user input clients such as a keyboard, mouse, touch pad, or other client. For simplicity of description, conventional components above and more of client 100, such as one or more computer processors, local fixed memory (e.g., RAM and ROM) and optionally removable memory (e.g., SD card and U-disk), power supplies, audio-visual output clients, etc., are not shown. The client 100 may also include additional components such as a camera or a positioning module. A camera may be used to capture images or video. The location module determines the location of the client 100 using, for example, global positioning satellite signals, cellular data, base station signals, network data, or other methods. The local application 220 or the local file collaboration program 240 may use the location module to obtain location data and add the location data to metadata of the relevant file, such as an image captured by a camera.
The client 100 can access the server 110 in various ways. The local file collaboration program 240 may be a dedicated application or module that provides access to the services of the server 110, either through a user interface to shared files or through a corresponding interface or protocol to other applications. Alternatively, the local file collaboration program 240 may integrate access to the server 110 with a local file management system provided by the operating system 210. When access to the server 110 is integrated into the local file management system, the file organization scheme stored and maintained on the server 110 may be represented as a local file structure by the local file collaboration program 240 in conjunction with the operating system 210. The local file collaboration program 240 may be implemented in various forms, such as a standalone application, an application plug-in, or a browser extension, among others.
The operating system 210 may process and identify various events. Such events include a request from the local application 220 to close, open a file or content item, and so forth. As described below, these events may be monitored and extracted by the file collaboration program 240 and used to identify operations or changes related to the file. Events managed and controlled by the operating system 210, which may be referred to as system events, and various information and data that can be extracted from these events are related to the operating system 210 and do not depend on the local application 220 or other applications.
The local file collaboration program 240 may identify interactions that occur with respect to files, such as when a user opens, closes, or edits a file on the client 100. These interactions are monitored or identified by the local file collaboration program 240 to generate interaction information describing the interactions with the file. The interaction information may include interactions with the file collaboration program 240 as well as interactions with the local application 220. Other types of interaction information may also include file-related status information, comments, messages, notification requests, etc., which may be obtained by the file collaboration program 240. The messages may include notification messages with other clients 100, messages indicating that the user intends to interact with (e.g., open, edit, save, update) the file, and messages indicating that the user intends to begin a collaborative edit or conversation.
The notification request may include a request to be notified when the interaction information of another user changes. The interaction information may also include metadata modifications, such as a version specification or a request for further information about the associated file stored on the server 110, such as a request to view version information or previous file versions.
The interaction information may be sent to other clients 100 that share or synchronize the file, such as issuing a warning to other users at another client regarding the file, the other users wanting to edit the file or initiate an editing session, and so forth. The local file collaboration program 240 may identify when a user interacts with a file using the local application 220 and may also receive input information from the user. In various embodiments, the user's presence in a file (e.g., the user has a file open or content being edited) may be identified through interaction with the operating system 210.
The client 100 may receive the file or updated version of the file from the local file collaboration program 240 and allow the user to view, modify, and interact with the file using various local applications 220 stored or running on the client 100. For example, the client 100 may include an image editing application that operates on image content, a word processing application that allows modification of textual content, or a Computer Aided Design (CAD) application that allows modification of graphical content, among other things. The interaction information is determined by the client 100 via the user interaction application, and the interaction information may be transmitted to other clients 100. In addition, when the client 100 receives interaction information related to other clients 100, the client 100 may display the interaction information, for example, in the form of user interface elements.
In some embodiments, the application that detects the interaction information related to the file is different from the application that views or manipulates the file. For example, an application program that detects the interactive information is different from a photo editing application program that operates or displays image content. In various embodiments, the application that detects the interaction information is also responsible for synchronizing the file with the server 110, may monitor for various applications, files, or content, or integrate monitoring into each type of file viewer. For example, for each of a photo editing application, a word processing application, and a playlist editing application, a generic monitoring plug-in or application may be used, or a specific monitoring plug-in or application may be used separately.
In some embodiments, clients 100 sharing or synchronizing a file may collaboratively edit the file. A collaborative user (or entity) may open, view, or edit a file in the local application 220. In some embodiments, two or more collaborating users may edit the file simultaneously during collaboration. The collaborative users can change the content visible to other collaborative users in real time and check the changes made to the file and the content thereof by other collaborative users. In some embodiments, user collaboration is managed by the local file collaboration program 240.
The local file collaboration program 240 may include a relay lock service detection module 241, a relay lock logic module 242, an access interception module 243, and an access monitoring module 244.
The client 100 is provided with a shared folder or a shared file system locally, and the access monitoring module 244 can monitor access operations of files or folders therein. When it is detected that an application (e.g., the local application 220) accesses the shared file, the access can be intercepted by the access intercepting module 243, and the access is denied or allowed according to specific situations. In addition, system events (e.g., Close File) that share folders or share files or folders within the File system can also be monitored.
The relay lock service detection module 241 is configured to detect whether the relay lock logic module 242 operates normally, so as to ensure that a file or a folder inside a shared folder cannot be opened when the relay lock logic module 242 does not operate, or the relay lock logic module 242 can be successfully invoked before the file or the folder is opened.
The access interception module 243 can intercept file access operations in the shared folder or the shared file system, and determine whether to allow or block the access operation after interacting with the relay lock logic module 242.
The access lock service detection module 241, the access interception module 243, and the access monitoring module 244 may be a file system implemented by a driver or an application program itself, or implemented in the form of file manager software, and are intended to intercept file access operations and monitor events of a file or folder system.
In some embodiments, the file system is part of the operating system, and file system events are monitored and issued by the operating system, which may be intercepted, or processed by a driver or its own application.
In some embodiments, a file manager software may also be written or configured to have a similar function as the operating system's resource manager, and then hide the local folders and their files in the operating system so that the user can only access these files through this file manager software, which is equivalent to replacing the operating system's own file system or resource manager with the file manager software. Because the user operates the files through the additionally written or set file manager software interface, the file manager software can know what operations the user does, and each operation record of the user can be monitored and intercepted by the file manager software, so that the monitoring of events of the operating system is not needed.
The baton lock logic module 242 is capable of communicating with the server 110, obtaining the lock status and the exclusive condition of the shared file from the server 110, and determining whether to allow access to the shared file according to the lock status and the exclusive condition. The access intercepting module 243 can intercept or release the access operation to the shared file according to the judgment result of the relay lock logic module 242.
Fig. 3 is a block diagram of an embodiment of the server 110 according to the present application. As shown in fig. 3, the server 110 may include an online file collaboration module 340, a storage module 310. For the sake of brevity, various other necessary or optional software and hardware modules, devices that the server 110 may include are not shown, such as: processors, memory, display devices, input devices, network interfaces, operating systems, application programs, and the like.
The online file collaboration module 340 may manage and process shared files and related information stored on the server 110 and may interact with the local file collaboration program 240 of the client 100 to process and synchronize shared files among multiple clients 100 and servers 110. For example, if a first entity (user) of the client 100A modifies a shared file, the local file collaboration program 240 of the client 100A can upload the modification information and the modified final version of the file to the server 110 through the online file collaboration module 340, so as to update the file stored on the server 110 to the modified final version, and perform corresponding recording or marking. Later or simultaneously, the file collaboration module 340 may further transmit the file to other clients 100B and 100C storing the file, so as to update the file stored on the clients 100B and 100C to the modified final version.
In some embodiments, multiple clients 100 may also interact through the online file collaboration module 340 of the server 110. For example, in a situation where a first entity at the client 100A is operating or editing a shared file, and a second entity at another client 100B opens the file and attempts to modify the file, a corresponding notification or prompt message may be sent to the client 100A and the client 100B through the online file collaboration module 340, for example, a message is sent to the second entity at the client 100B to prompt that the file is being edited by the first entity at the client 100A, so that the second entity may take operations such as closing the file, abandoning the operation, issuing a collaborative editing request, and the like; a message is sent to the first entity at the client 100A, prompting the occurrence of an operation or request of the other entity for the file, so that the first entity can take operations of closing the file, saving the file, accepting the collaborative editing request, and the like.
The storage module 310 can store shared files and information related to the shared files, such as lock status, exclusive conditions, file clusters and associations of the shared files. The server 110 will record the file status of all shared files or file clusters, which is mainly composed of two parts:
(1) locking state: there are two values, Locked and Unlocked, for identifying whether the file is currently occupied by a person.
(2) Exclusive conditions: the next visitor monopolizes the condition that needs to be satisfied for the file.
Based on the above-mentioned client 100 and server 110, the present application provides a method and system for file access control, which is described in more detail by way of example below.
The file access control method provided by the application can comprise the following steps:
step one, when monitoring the access operation of the target file, acquiring the locking state and exclusive condition of the target file.
And step two, judging whether the target file is allowed to be accessed or not according to the locking state and the exclusive condition. If the locked state is unlocked and the exclusive condition is satisfied, access to the target file is permitted.
In some embodiments, the lock status may be determined prior to determining the exclusive condition. If the locking state is locked, the target file is not allowed to be accessed, and the exclusive condition is not judged any more. If the locking state is not locking, then judging the exclusive condition. If the locking state is not locked and exclusive us is satisfied, allowing access to the target file; if the locked state is not locked but does not satisfy the exclusive condition, access to the target file is not allowed.
In some embodiments, target files, as well as other files and/or folders associated with the target files, may form clusters of files based on associations. Other files and/or folders in the file clusters have the same lock status and exclusive conditions as the target files. When the target file is operated, other files and/or folders in the file cluster are operated correspondingly according to the association relation. For example, when the locking state of the target file is modified to Locked, the locking states of other files and/or folders in the file cluster are also modified to Locked, so that in the process of accessing the target file by a certain user, other files and/or folders in the file cluster are not allowed to be accessed by other users, and all files in the file cluster are kept consistent.
In some embodiments, a folder in which a file or a file cluster is located can be mapped to a drive using a related tool (e.g., a subst, etc.) on a client to ensure that the file and the folder have the same file path on different clients. This approach may be beneficial for certain software that rely on the path of a file or the absolute path of a file (e.g., Autodesk review software).
In some embodiments, for the case of a file cluster, it may first be determined whether a target file belongs to a member of a file cluster: if yes, the locking state of the file cluster is taken as the locking state of the file cluster (one person is locked, the whole family is locked), and the exclusive condition is also the exclusive condition of the file cluster; if not, processing according to a single file. Indeed, a single file may also be viewed in a sense as a file cluster having only one member.
In this step, it may be determined whether the current content of the local target file is consistent with the previously (or latest, final, latest, or last) saved content of the target file according to information included in the exclusive condition, so as to determine whether the exclusive condition is satisfied. The exclusive condition is used for judging whether the local file is consistent with the recently updated public version, and the exclusive condition may include a direct condition and/or an indirect condition according to the obtaining way of the judgment information.
The direct condition can be directly used to determine whether the current content of the local target file is consistent with the content of the target file stored last time, and the direct condition may include one or more of the following information: the version number of the file; a Hash value of the file; the previous modification time of the file; the characteristic value of the file.
The indirect condition is used for obtaining the direct condition and/or obtaining the latest version of the target file, and the indirect condition may include one or more of the following information: the communication mode of the previous visitor of the file; and obtaining the last saved version of the file. Compared with the method that the server stores complete judgment information (direct condition), the server stores a 'key' (indirect condition) for acquiring the complete judgment information, and the client acquires the complete judgment information after taking the 'key', so that the occupied space of the server can be effectively reduced.
In some embodiments, the related information for comparing the files may be obtained according to an indirect condition, for example, a Hash value of a Hash code, a Hash tree, or the like of the file. When the files are judged to be inconsistent, data for updating the files are further acquired, for example, the whole files are directly downloaded according to indirect conditions.
In some embodiments, the exclusive condition includes a Hash value of a previously saved file, and whether the current content of the target file is consistent with the previously saved content may be determined by comparing the Hash value of the target file with the Hash value in the exclusive condition, so as to determine whether the exclusive condition is satisfied.
In some embodiments, the exclusive condition includes a self-added version number of the file (the modified file is updated with a corresponding version number, and the updated file has a version number greater than that of the previous file), the determination may be made by comparing the version number of the target file with the version number in the exclusive condition, and different cases can be distinguished to take corresponding measures.
And if the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file, and meeting the exclusive condition.
If the version number of the target file is smaller than the version number in the exclusive condition, it indicates that the current version of the target file is older, and the target file needs to be updated, at this time, the synchronous update operation of the file may be performed normally, for example, the user may be prompted or the target file may be automatically updated to the latest version (i.e., the version that is finally saved by the previous user).
If the version number of the target file is greater than the version number in the exclusive condition, it may be determined that an error such as abnormal unlocking has occurred. For example, after the previous user locks, abnormal shutdown, client crash, and the like occur, so that normal unlocking is not performed, and then unlocking is performed forcibly due to lock timeout or by an administrator. At this time, the user can be reminded whether to save the file additionally or not, so as to prevent the loss of the work content.
In some embodiments, the server does not directly store the verification conditions for verifying the contents of the file, but stores the manner in which the verification conditions are obtained. For example: the exclusive condition includes a communication manner (indirect condition) of the previous user so that the current visitor can directly communicate with the previous user to acquire a verification condition (direct condition) for comparing and verifying the file content from the previous user to perform verification of the file content, thereby determining whether the exclusive condition is satisfied.
In some embodiments, the previous visitor may communicate with the exclusive condition according to a communication manner of the previous visitor to obtain a direct condition for comparing whether the current content of the target file is consistent with the previously saved content of the target file from the previous visitor, so as to compare whether the current content of the target file is consistent with the previously saved content of the target file; the last saved version can also be obtained according to the obtaining mode of the last saved version in the exclusive condition so as to update the target file. In this embodiment, the direct condition may be stored at the previous visitor, or may be generated by performing a corresponding operation when communicating with the previous visitor through the indirect condition.
As an example, in the scenario of P2P or accelerated synchronization of local area network, the exclusive condition may be the communication mode (e.g. IP address) of the previous user (i.e. the last locker), and the current user (i.e. the current visitor) will directly communicate with the previous user to obtain the characteristic value of the local file of the previous user for verification. The characteristic value of the file can be stored in the former user and can be directly obtained through indirect conditions; or newly generated by performing corresponding operations when communicating with the previous user through indirect conditions. When the verification result indicates that the feature values of the file are inconsistent, the latest version of the file can be pulled from the previous user directly in the manner of P2P.
Since the immediate condition needs to be stored or derived by computation, and the immediate condition does not need to be used until the next user accesses the file. Therefore, the indirect condition for acquiring the direct condition is normally stored in the server, and the direct condition is acquired or calculated in a certain mode when the direct condition needs to be used, so that the storage space can be effectively saved, and the execution time can be optimized. For example, the last condition used as the exclusive condition for judgment is a version number, a Hash value and other direct conditions, but before the next user edits, the version number and the Hash value are not used, so that the version number and the Hash value can be obtained or calculated after being delayed until the version number and the Hash value are really needed, resources do not need to be consumed in advance for storage or calculation, storage space can be saved, and initial execution time can be optimized.
And step three, after the target file is accessed, completing the operation before unlocking, updating the exclusive condition, and modifying the locking state into non-locking. The pre-unlock operation may include one or more of: closing the target file; saving the target file; uploading the stored target file to a server; uploading a folder associated with the target file to a server; and carrying out corresponding operation on the file cluster to which the target file belongs and other files included in the file cluster. This can provide the latter user with a "continue editable" file without risk of file conflict.
Fig. 4 is a schematic architecture diagram of an embodiment of a file access control system in the present application. As shown in fig. 4, when it is detected that an exclusive access operation is applied to a shared target file (or folder), the baton lock service detection module 241 inquires of the baton lock logic module 242 whether it is running. The baton lock logic module 242 responds to the inquiry and returns its own operational status to the baton lock service detection module 241. The access lock service detection module 241 determines to intercept or release the access operation according to the result returned by the inquiry. If the relay lock logic module 242 operates normally and returns a signal indicating a normal operation state to the relay lock service detection module 241, the relay lock service detection module 241 releases the access operation. If the relay lock logic module 242 does not operate normally, a signal indicating an abnormal operation state is returned to the relay lock service detection module 241, or the relay lock service detection module 241 does not receive the return signal from the relay lock logic module 242, the relay lock service detection module 241 intercepts the current access operation. This ensures that the access operation is performed when the baton lock logic 242 is operating properly.
When receiving the access operation request, the access intercepting module 243 queries the relay lock logic module 242 whether to release the access operation. The power lock logic 242 responds to the query and further requests the file status of the target file from the server 110. The server 110 responds to the request by returning the locked state and exclusive condition of the target file to the baton lock logic module 242. The access lock logic module 242 determines whether to allow the current access operation according to the acquired locking state and exclusive condition, and returns the determination result to the access intercepting module 243. The access intercepting module 243 intercepts or releases the access operation according to the judgment result returned by the relay lock logic module 242. If the relay lock logic module 242 determines that the current access operation can be allowed, the access intercepting module 243 passes the current access operation and the target file can be accessed. If the access lock logic module 242 determines that the access operation cannot be allowed, the access interception module 243 intercepts the access operation, and the target file cannot be accessed, so as to avoid file collision caused by accessing the target file.
In the present application, the access operation performed on the file may include various operations such as opening, reading, modifying, editing, saving, and updating the file. In some embodiments, when it is determined that there is a risk of file conflict, different processing modes may be selected according to different types of access operations, for example, an operation of opening in a read-only mode may be allowed without allowing operations of modification, editing, and the like. In some embodiments, when it is determined that there is a risk of file conflict and access operation is not allowed or is intercepted, a prompt may be further provided to the user to guide the user to take a corresponding more secure operation, such as opening the target file in a read-only manner or first updating the target file to a latest modified version. In the present application, for convenience of description, specific operation types are not distinguished, and are generally described as access operations in a unified manner.
Fig. 5 is a schematic file state transition diagram of an embodiment of a file access control method in the present application, and illustrates a process of server file state transition. As shown in fig. 5, in the initial state, i.e. for a newly established or newly added shared file, the lock state is Unlocked, the exclusive condition is Null (indicating that the condition is Null or no condition), i.e. there is no restriction, and anyone is qualified for exclusive.
And the user 0 starts to access the file, and the locking state of the file is modified to be Locked, so that the file is monopolized in the access process, and other users are not allowed to access the file. When the user 0 finishes accessing the file, a corresponding exclusive condition is given, and the locking state is modified into Unlocked for subsequent other users to access.
When the user N tries to access the file, the locking state of the file is judged to be Unlocked, and the exclusive condition given by the previous user N-1 is met, so that the user N is allowed to access the file. And the user N starts to access the file, and the locking state of the file is modified into Locked, so that the file is monopolized in the access process, and other users are not allowed to access the file. At this time, the exclusive condition of the file is not updated by the user N, and the exclusive condition of the file is still maintained as the exclusive condition given by the previous user N-1. However, at this time, since the Locked state of the file is Locked, and other users are not allowed to access the file, it is not necessary to determine whether the exclusive condition is satisfied, and the exclusive condition is meaningless in the process of accessing by the user N. When the user N finishes accessing the file, a corresponding exclusive condition is given and updated, and the locking state is modified into Unlocked for subsequent other users to access.
When the latter user N +1 tries to access the file, the judgment is carried out according to the updated locking state and exclusive condition after the user N finishes accessing so as to judge whether the user N +1 is allowed to access. If the locked state is Unlocked and the exclusive condition given by the previous user N is satisfied, then user N +1 is allowed access. And the user N +1 starts to access the file, and the locking state of the file is modified into Locked, so that the file is monopolized in the access process, and other users are not allowed to access the file. At this time, the user N +1 does not update the exclusive condition of the file, and the exclusive condition of the file remains as the exclusive condition given by the previous user N. When the user N +1 finishes accessing the file, giving and updating a corresponding exclusive condition, and revising the locking state to Unlocked for subsequent other users to access. The access process of more users is similar to the above process of user N and user N + 1.
By the method, each user accesses according to the exclusive condition given by the previous user, gives the latest exclusive condition after finishing accessing, and then transmits the latest exclusive condition to the next user, namely, the file lock is transmitted among the users in a relay manner, so that the user N is strictly ensured to edit based on the edition of the previous user N-1, the consistency of the file is ensured, and the generation of file conflict is effectively prevented.
The application also provides a file access control system which can comprise a client and a server. The server is configured to be able to save the lock state and exclusive condition of the target file. The client may include: the system comprises a relay lock logic module, an access interception module, a relay lock service detection module and an access monitoring module.
The access lock logic module is in communication connection with the server and configured to acquire a locked state and an exclusive condition of the target file from the server when an access operation to the target file is monitored, and judge whether to allow the target file to be accessed according to the locked state and the exclusive condition. The access intercepting module is configured to intercept or release the access operation on the target file according to the judgment result of the relay lock logic module. The relay lock service detection module is configured to detect whether the relay lock logic module is operating normally. And the access monitoring module is configured to monitor the access operation of the target file.
In some embodiments, the baton lock logic module is further configured to determine the lock status before determining the exclusive condition. If the locking state is locked, the target file is not allowed to be accessed, and the exclusive condition is not judged any more. If the locking state is not locking, then judging the exclusive condition. If the locking state is not locked and exclusive us is satisfied, allowing access to the target file; if the locked state is not locked but does not satisfy the exclusive condition, access to the target file is not allowed.
In the case of a file cluster, the relay lock logic module is further configured to be able to first determine whether a target file belongs to a member of a file cluster: if yes, the locking state of the file cluster is taken as the locking state of the file cluster (one person is locked, the whole family is locked), and the exclusive condition is also the exclusive condition of the file cluster; if not, processing according to a single file. Indeed, a single file may also be viewed in a sense as a file cluster having only one member.
The file cluster module can be used to record and retrieve file cluster list information, i.e., to answer whether a file is a member of a file cluster, and specifically which file cluster. The access lock logic module is used for judging whether to allow the access. In some embodiments, the file cluster module may be a built-in part of the baton lock logic module.
In some embodiments, the baton lock logic module is further configured to determine whether the current content of the target file is consistent with the previously saved content of the target file according to information included in the exclusive condition, so as to determine whether the exclusive condition is satisfied.
In some embodiments, the baton lock logic module is further configured to compare the version number of the target file with the version number in the exclusive condition and determine whether the current content of the target file is consistent with the previously saved content of the target file. If the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file; if the version number of the target file is smaller than the version number in the exclusive condition, judging that the target file needs to be updated; and if the version number of the target file is greater than the version number in the exclusive condition, judging that an error occurs.
In some embodiments, the baton lock logic module is further configured to communicate with the previous visitor based on the previous visitor's communication in the exclusive condition to compare whether the current content of the target file is consistent with the previously saved content of the target file.
In some embodiments, the baton lock logic module is further configured to obtain the previous saved version according to the obtaining manner of the previous saved version in the exclusive condition, so as to update the target file.
When a target file belongs to a file cluster, the client can be configured to perform corresponding operations on other files and/or folders in the file cluster according to the association relationship when the target file is operated.
The client is further configured to complete the pre-unlocking operation after accessing the target file, update the exclusive condition, and modify the locking state to be non-locking.
Fig. 6 is a flowchart illustrating an embodiment of a file access control method according to the present application. As shown in fig. 6, when an application exclusive access operation is monitored, it is first detected whether the access lock service is opened. And if the relay lock service is not opened, the access is refused, or the relay lock service is invoked.
If the relay lock service is opened, the current (or latest and updated after the previous storage) locking state and exclusive condition of the file can be acquired from the server to continuously judge whether the access is allowed or not. And if the locking state is locked, the access is refused. And if the locking state is non-locking, judging whether an exclusive condition is met.
If the exclusive condition is not met, triggering related operation to enable the file to meet the exclusive condition, obtaining the locking state and the exclusive condition of the file from the server again, and continuing to judge whether the access is allowed or not in a similar manner.
If the exclusive condition is met, a locking request is sent to the server, the locking state of the file is modified to be locked, and the file is exclusive and the access is allowed.
When the access is finished, the file is synchronized with the server or other clients to synchronously update the copy of each file to the finally saved version, and then an unlocking request is sent to the server. When the server unlocks the file, the exclusive condition is updated, and then the locking state is changed into non-locking state.
In some embodiments, the file access control method may comprise the steps of:
the method comprises the following steps: when an application tries to exclusively access a certain file copy under the synchronization folder, the operation is firstly intercepted by the relay lock service detection module to check whether the relay lock service process is started or not: if not, refusing the access and exiting the process; if the starting is finished and the operation is normal, the step two is continuously executed.
Step two: the operation will be intercepted by the access interception module and the baton lock logic module is queried as to whether the operation is allowed.
Step three: the access lock logic module will request the current state of the file (acquire locked state and exclusive condition) from the server and execute as follows:
(1) if the locking state is Unlocked, and the local file state meets the exclusive condition: firstly, sending a notice to a server, and locking the file with the identity of the current machine (modifying the locking state of the file on the server to Locked); and then the present exclusive access operation is released.
(2) If the locking state is Unlocked, but the local file state does not meet the exclusive condition: triggering the relevant operation to satisfy the condition (such as pulling the latest version of the file from the server), and keeping the blocking of the access operation in the period; and then returning to execute the third step.
(3) If the Locked state is Locked: and ignoring the exclusive condition, directly preventing the exclusive access operation, and exiting the process.
Step four: when the exclusive access of the application is completed (e.g., a Close File event of the File system is detected), the following steps are performed: wait for the unlocking prerequisite to complete, for example: waiting for the complete uploading of the related files or folders to the server; the file state is then updated to the server, including:
(1) updating an exclusive condition (given by a user who currently completes an exclusive operation);
(2) the lock status is modified to Unlocked.
In some embodiments, the following may be done for the exception case:
(1) and (3) network exception: before the server returns to the locked state, the access interception module will keep blocking the modification operation, i.e. it cannot access the file. The scheme of the application simulates the use scene of Windows Shared Folder under the condition of multiple file copies, namely the scene of remotely accessing the same file. Therefore, it is reasonable that the network is abnormal and cannot access the file.
(2) The client is restarted or abnormally crashed, the computer is shut down and other accidents cause that the locked file cannot be unlocked as expected: from the perspective of "emulating remote access to the same file", these phenomena should be handled as a network exception ("drop"), i.e., the "remote file" would be immediately unlocked and the user's unsaved content would be immediately lost. However, in the scheme of the application, the locked state is still maintained until the working state of the user returns to normal, so that the editing loss of the user is avoided as much as possible. Of course, the administrator may be allowed to forcibly unlock the server, or automatically unlock the server by setting an expiration time, which may cause the editing of the user to be lost.
In the embodiment of the application, the relay lock service detection module and the access interception module may be implemented by a relay lock service detection driver and an access interception driver, respectively, or may be replaced by a file system implemented by the relay lock service detection driver and the access interception driver, so as to meet the interception requirement on access. The baton lock logic module may be an independently running process.
In some embodiments, the exclusive condition is "file version number", and the file access control method may include the steps of:
the method comprises the following steps: when an application tries to exclusively access a certain file copy under the synchronous folder, the operation is intercepted by a relay lock service detection driver firstly to check whether a relay lock logic process is started or not: if not, refusing the access and exiting the process; if the starting is finished and the operation is normal, the step two is continuously executed.
Step two: the operation will be accessed to the intercept driver and ask the baton lock logic process whether the operation is allowed.
Step three: the access lock logic process will request the server for the current lock state and file version number of the file and execute as follows:
(1) if the locking state is Unlocked, and the version number of the local file is equal to the version number of the server file: firstly, sending a notice to a server, and locking the file with the identity of the current machine (modifying the locking state of the file on the server to Locked); the driver then passes the exclusive access operation this time.
(2) If the locking state is Unlocked, but the version number of the local file is smaller than that of the server file: firstly, pulling the latest version of a file/file cluster from a server, updating a local file and a version number, and keeping the prevention of access operation in the period; then returning to execute the third step;
(3) if the locking state is Unlocked, but the version number of the local file is greater than the version number of the server file: and e, indicating that the local file is abnormally unlocked, prompting the user to back up the local file, covering the local version with the server version, and returning to the step three.
(4) If the Locked state is Locked: and directly preventing the exclusive access operation and exiting the process.
Step four: when the access interception driver detects a closing event of a certain file in the file cluster, which indicates that the user finishes editing, the following operations are performed: uploading a local file/file cluster to a server, and waiting for the operation to be completed; the file state is then updated to the server, including:
(1) update file version number, such as: if the version number before editing is N, modifying the version number to be N +1 after editing;
(2) the lock status is modified to Unlocked.
In some embodiments, where the exclusive condition is "file Hash" and the P2P is used to synchronize the files, the file access control method may include the following steps:
the first and second steps are similar to the above embodiments.
Step three: the access lock logic process will request the server for the current lock status of the file, the file Hash and the IP address of the last editor (user N-1), where the file Hash can be chosen differently depending on the situation:
(1) when the file is small (less than a certain threshold, such as less than 4M): directly carrying out Hash calculation on the whole file;
(2) when the file is large (greater than some threshold, such as greater than 4M): the file is partitioned to calculate the Hash, so the file Hash will be a Hash list, where the operation is similar to the incremental synchronization algorithm.
(3) For the case of a particularly large number of files in a file cluster: a mesh Tree, i.e. a Hash Tree, can be used, so that the server only needs to store a top Hash (top Hash) or a root Hash (root Hash) for verification, and does not need to maintain particularly much information. The Hash tree information may be received by P2P or elsewhere and then checked against the top Hash retrieved from the trusted server.
Since the Hash Tree (mesh Tree) covers both the Hash list and the Hash value (i.e. the Hash list is a special column of the Hash Tree), the following steps are exemplified in the case of the Hash Tree, and the rest of the cases are similar. After the user N obtains the top Hash of the file cluster and the IP address of the user N-1:
(I) if the locking state is Unlocked, acquiring a Hash tree from a user N-1 through an IP address of the user N-1, verifying the Hash tree with the top Hash, and if the Hash tree does not pass the verification, indicating that the Hash source is not credible, sending a warning to the user to request the user to acquire the Hash from a reliable source and quitting the process; if the verification is passed, the Hash tree is proved to be credible, and the Hash is compared with the Hash tree of the local file cluster: if the file is consistent with the exclusive access operation, sending a notification to the server, modifying the locking state of the file on the server into Locked, and allowing the drive to release the exclusive access operation; if not, the latest version of the relevant file is acquired from the user N-1 through the IP address of the user N-1 to update the local file and the Hash tree, the access operation is prevented in the period, and the step III is returned to the execution step after the update is finished;
(II) if the Locked state is Locked: and directly preventing the exclusive access operation and exiting the process.
Step four: when the access interception driver detects a closing event of a certain file in the file cluster, which indicates that the user finishes editing, the following operations are performed:
(1) recalculating and storing the Hash tree of the local file;
(2) submitting the top Hash of the latest Hash tree and a local IP address to a server;
(3) the lock status is modified to Unlocked.
Hash is a function that maps data of arbitrary length into data in one-to-one correspondence, and theoretically satisfies the condition of 'single shooting', namely one-to-one, rather than one-to-many or many-to-one. Through a specific calculation mode, data or files with larger length can be mapped to data with smaller length. When comparing data or files, if the data or files are large, the time efficiency and the space efficiency of the comparison are low, and if the communication of the data is involved, the communication cost is high. And the Hash is used for mapping the larger data or files into the one-to-one corresponding smaller data, and then the comparison is carried out, so that the time efficiency and the space efficiency of the comparison can be effectively improved, and the communication cost is lower.
In some embodiments, for data integrity check, Hash operation may be performed on the entire data before data transmission to obtain a Hash value of a fixed length, then, after the user obtains the data through data transmission, the Hash operation is performed on the data again, the operation result is compared with the previous Hash value, and if the two Hash values are equal, it is indicated that the obtained data is not damaged. This can be done because small changes in the input data can cause the Hash result to be completely imperfect and it is difficult to reverse-infer the characteristics of the original input data from the Hash value.
If the data volume is small and the data transmission channel is stable, the single Hash is preferably adopted. However, if the amount of data is large or the data transmission channel is not stable, the data needs to be retrieved once the data is damaged, which is inefficient. For the case of a large number or a data transmission channel that is not stable, a large file may be divided into small data blocks (e.g., into 2K data blocks) in order to verify the integrity and consistency of the data. This has the advantage that if a small piece of data is corrupted during transmission, it is sufficient to retrieve the corrupted fast data without having to re-download the entire file.
At this time, a Hash needs to be performed for each data block, so as to obtain a Hash List (Hash List). In order to verify the integrity and consistency of the Hash list, the Hash values of each small block of data may be pieced together, and then the long string is subjected to a Hash operation again, so as to obtain the Root Hash (Top Hash or Root Hash) of the Hash list. When data is acquired, firstly, a correct root Hash is obtained from a credible data source, the root Hash is used for verifying a Hash list, and then each acquired data block is verified through the verified Hash list.
A Merkle Tree (also known as a merkel Tree) can be regarded as a generalization of a Hash List (a Hash List can be regarded as a special Merkle Tree, i.e. a bifurcate Merkle Tree with a Tree height of 2). At the bottom level, as with the Hash list, the data may be divided into small chunks of data and corresponding Hash values. With the tree going upwards (calculating layer by layer from bottom to top), the root hash is not directly calculated, but two adjacent hash values are combined into a character string, and then the hash value of the character string is calculated, so that every two hash values are combined together to obtain a sub hash value. If the total number of the hash values at the lowest layer is singular, a 'single' hash value is necessarily generated at last, and the situation is that the hash value is directly hashed, so that the sub-hash value can also be obtained. And continuously pushing up according to the tree level, and obtaining a smaller number of new first-level hash values by using the same mode, so that an inverted tree can be formed finally. By the position of the tree Root, this generation leaves a Root Hash value (or Top Hash value), called Root Hash (or Top Hash).
Before obtaining data, a Root hash value, i.e., a Root Tree Root (Merkle Root) of a file, may be obtained from a trusted source, and then Merkle trees may be obtained from other trusted or untrusted sources. The received Merkle Tree is checked through the trusted Tree root. If the Merkle Tree is corrupt or spurious, another Merkle Tree is obtained from another source until a Merkle Tree matching the Trusttree root is obtained.
The main difference between the Merkle Tree and the Hash List is that a branch of the Merkle Tree can be directly obtained and immediately verified. Since the file can be cut into small data blocks, it is sufficient to retrieve only one data block if it is corrupted. If the file is very large, the Merkle Tree and the Hash list are both very large or much, but the Merkle Tree can acquire one branch at a time and then immediately verify the branch, and if the branch is verified, the corresponding data can be continuously acquired. And the HashList can be verified only by acquiring the whole HashList.
In the application, different Hash verification modes can be selected according to the conditions of files and networks. In some embodiments, the server may store multiple Hash values and optionally provide different authentication methods, for example, when one authentication method fails to perform authentication, it may switch to another authentication method. Similarly, besides the Hash value, the exclusive condition may also include a plurality of information such as a version number of the file, a feature value, a communication address of a previous user, and an acquisition mode of a file saved last time, so as to provide a corresponding verification or processing mode according to different situations, thereby enhancing compatibility and robustness of the system.
According to the file access control method and system, verification of the exclusive condition is added on the basis of the locking state of the file, whether the file meets the exclusive condition is checked before the operation of accessing the file is allowed, if the file does not meet the exclusive condition, the operation is stopped, so that the file is ensured to be a 'continuously editable' file version which is safe and reliable and has no file conflict risk, and the problem that the existing file locking mechanism cannot reliably prevent file conflict is effectively solved.
The application also provides a file access control method, which comprises the following steps:
when the access operation to the target file is monitored, whether the target file is contained in a certain file cluster is inquired. The target file may be in the form of a file or folder.
If the target file is contained in a certain file cluster, whether the access operation to the target file is allowed or not is further determined according to the state of the file cluster.
If access operations to the target files are permitted, the file cluster and/or other files contained in the file cluster are processed accordingly. Other files contained in a file cluster may be in the form of files or folders.
The file cluster comprises a file list, the file list comprises file identifications corresponding to each file in the file cluster, and whether a target file is contained in a certain file cluster can be inquired by retrieving the file list. If the file identification of the target file is contained in the file list, or the target file is subordinate to a folder in the file list, the target file is contained in the file cluster.
The status of file clusters may include one or more of the following: is locked; unlocking; the reading is carried out; can be written; can be deleted; monopolizing; its children can be manipulated. Each file contained in a file cluster may also have one or more of the states described above. In some embodiments, the file clusters and all files contained in the file clusters are in the same state. In other embodiments, the status of file clusters and each file contained within a file cluster may be different, but the status of a file cluster is the minimum authority status of all files in the file cluster.
The access operation may include one or more of the following operations: reading; writing; deleting; adding a file; subfolders are added. If the status of a file cluster is locked, then no access operations to the target file are permitted. If the state of a file cluster is unlocked and the access operation is delete, then the access operation to the target file is allowed and the target file is removed from the file cluster.
FIG. 7 is a block diagram of an embodiment of a file access control system according to the present application. As shown in FIG. 7, a file access control system includes a file cluster module that can store a plurality of file clusters. Each file cluster includes a list of files, including file identifications corresponding to each file in the file cluster. Each file in the file cluster may be in the form of a file or a folder. The files in the file clusters and the folders themselves are maintained in a file system.
The file access control system may further include an access monitoring module for monitoring and controlling access operations to the target file. When monitoring access operation on target files, inquiring whether the target files are contained in a file cluster, wherein the form of the target files comprises files or folders; and if the target file is contained in the file cluster, determining whether to allow an access operation to the target file according to the state of the file cluster.
The file access control system may further include means for processing the file clusters and/or other files contained in the file clusters accordingly when access operations to target files are permitted. The other files in the file cluster may be in the form of files or folders.
The access monitoring module can inquire whether a target file is included in a certain file cluster by retrieving a file list. If the file identification of the target file is contained in the file list or the target file is subordinate to a folder in the file list, the target file is contained in a file cluster.
In some embodiments, the access monitoring module does not allow access operations to target files when the status of a file cluster is locked. When the state of the file cluster is unlocked and the access operation is delete, the access monitoring module allows the access operation to the target file, and the associated operation module removes the target file from the file cluster.
In some embodiments, the principle of implementing the file cluster mechanism is to insert an intermediate layer between an operator of a file and a real file system, so that the operator of the file knows the file state of the real file system through a 'file cluster module' to determine whether to allow the operation, and synchronously update the data records of the file cluster during the actual operation.
One file cluster can record the following two information:
(1) status of file clusters: for reference to the validity and side effects of the procedure. In some embodiments the states are just Locked and Unlocked. In other embodiments, the status may include, but is not limited to: readable, writable, deletable, exclusive, whose child entries may be manipulated, and so on. The representation of the state may be a state flag applied to all files or folders contained in the file cluster, and the corresponding meaning may be determined by the actual implementation. In some embodiments, the state of a file cluster is the minimum permission state (intersection of states) of the files or folders it contains.
(2) List containing file identifications (e.g., list of file or folder IDs representing file identifications): the file ID is unique within the file system and the corresponding file can be found by the ID. In some embodiments, the file ID may be a path of the file. In some embodiments, the same ID may not be included in multiple file clusters and may not be a sub-entry of IDs in other file clusters, i.e., there may not be an intersection between ID lists of file clusters in the same system, which may avoid generating operation conflicts.
In some embodiments, initially, an empty file cluster may be created and its state initialized. Then, a file or folder ID is added to its ID list. When a user reads, writes, deletes, adds a file or a subfolder to a file or a folder, the file cluster module will put the ID of the file or the folder into a file cluster list for retrieval, and the matching conditions can be two types:
(1) and (3) complete matching: i.e., the operated-on file or folder is an item in the list of file cluster IDs.
(2) Comprises the following steps: i.e., the operated-on file or folder is a child of a folder in the list of file cluster IDs.
If no matched file cluster exists, the target file does not belong to any file cluster, and the file or the file folder is processed in a common mode. If there is a matching file cluster, the state of the file cluster is checked to determine whether to execute the operation and the side effect corresponding to the operation.
For example: when a user reads or writes a file of "folder a/file a.docx", it is known by the file cluster module that it belongs to "file cluster 0001", and the file cluster is in a Locked state, so that this access is prevented.
For example: when the user deletes "folder C/folder A", it is known by the file and cluster module that it belongs to "folder and cluster 0002", and that the file and cluster is in an Unlocked state, so this operation is allowed to be performed, and the "folder C/folder A" path (i.e., corresponding side effect) is removed in the file and cluster ID list.
The file cluster mechanism can enhance the multi-end strong consistency of the interface lock, and the working mode of the file cluster mechanism is described by taking a Central Model (Central Model) of an Autodesk Revit as an example (the Autodesk Revit is a set of series software of Eureke company, is used in the field of BIM (building information Model), can help architects to design, build and maintain buildings with better quality and higher energy efficiency, and is one of the most widely used software in BIM systems in the building industry of China).
The Central Model of Autodesk Revit contains a "filename. rvt" file and a "filename _ backup" folder. When the user edits and synchronously saves the 'filename rvt', a plurality of 'dat files are newly added under the' filename _ backup 'folder, and the original' dat files are kept unchanged. If these are synchronized to the other end independently at this time, a conflict will occur. Therefore, it is possible to associate the "filename. rvt" file and the folder of "filename _ backup" through a file cluster mechanism, and decide whether or not to perform a synchronization operation on the files inside the folder of "filename _ backup" by detecting the lock state of the "filename. rvt" file.
This embodiment may be considered in practice as: "filename rvt" and "filename _ backup" are originally the same "file". One example of this is microsoft office software ". multidot. docx" files, which are actually a ". multidot. zip" compressed package, when decompressed, can be found to contain a large number of scattered data files, but merely packed together to form a single "file" in appearance, and can be handled as a single file. However, the Central Model of Autodesk Revit does not have the packaging process, but also needs to perform corresponding operations on a plurality of files. In a similar situation, users cannot change this "bulk" file structure, and thus can be aided in forming strong associations by a file cluster mechanism.
In some embodiments, the present application further provides a computer apparatus, device or terminal, an internal structure of an embodiment of which may be as shown in fig. 8. The computer apparatus, device or terminal includes a processor, a memory, a network interface, a display screen and an input device connected by a system bus. The processor is used for providing calculation and control capability, and the memory comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program to run in the non-volatile storage medium. The network interface is used for communicating with an external terminal through network connection. The computer program is executed by a processor to implement the various methods, procedures, steps disclosed in the present application, or the processor executes the computer program to implement the functions of the respective modules or units in the embodiments disclosed in the present application. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell, an external keyboard, a touch pad or a mouse and the like.
Illustratively, a computer program may be partitioned into one or more modules or units that are stored in a memory and executable by a processor to implement aspects of the present application. These modules or units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution of a computer program in an apparatus, device or terminal.
The device, the equipment or the terminal can be computing equipment such as a desktop computer, a notebook computer, a mobile electronic device, a palm computer, a cloud server and the like. It will be appreciated by those skilled in the art that the configurations shown in the figures are block diagrams of only some of the configurations relevant to the present disclosure, and do not constitute limitations on the apparatus, devices or terminals to which the present disclosure may be applied, and that a particular apparatus, device or terminal may include more or less components than shown in the figures, or may combine certain components, or have a different arrangement of components.
The Processor may be a Central Processing Unit (CPU), other general or special purpose Processor, a microprocessor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. The processor is the control center of the above-mentioned apparatus, device or terminal, and connects the respective parts of the apparatus, device or terminal by using various interfaces and lines.
The memory may be used to store computer programs, modules and data, and the processor may implement various functions of the apparatus, device or terminal by executing or executing the computer programs and/or modules stored in the memory and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like; the data storage area may store various types of data (such as multimedia data, documents, operation histories, etc.) created according to the application, and the like. In addition, the memory may include high speed random access memory, and may also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), a magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.
The present application also provides a computer-readable storage medium having stored thereon a computer program which, when being executed by a processor, carries out the steps of the above-mentioned method. It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
The above-described apparatus or terminal device integrated modules and units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer-readable storage medium. Based on such understanding, the present application can realize all or part of the flow of the disclosed methods, and can also be realized by a computer program for instructing relevant hardware to complete, the computer program can be stored in a computer readable storage medium, and the computer program can realize the steps of the above methods when being executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, recording medium, U.S. disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution media, and the like. It should be noted that the computer readable medium may contain content that is appropriately increased or decreased as required by legislation and patent practice in the jurisdiction.
In some embodiments, the various methods, procedures, modules, devices, apparatuses, or systems disclosed herein may be implemented or performed in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, computing devices, computers, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices that perform some or all of the operations of a method in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for performing one or more operations of a method. The above description is only for the preferred embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art should be considered to be within the technical scope of the present application, and equivalent alternatives or modifications according to the technical solutions and the inventive concepts of the present application, and all such alternatives or modifications are encompassed in the scope of the present application.
Embodiments of the present application may be implemented in hardware, firmware, software, or various combinations thereof, and may also be implemented as instructions stored on a machine-readable medium, which may be read and executed using one or more processing devices. In some implementations, a machine-readable medium may include various mechanisms for storing and/or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable storage medium may include read-only memory, random-access memory, magnetic disk storage media, optical storage media, flash-memory devices, and other media for storing information, and a machine-readable transmission medium may include various forms of propagated signals (including carrier waves, infrared signals, digital signals), and other media for transmitting information. While firmware, software, routines, or instructions may be described in the above disclosure in terms of performing certain exemplary aspects and embodiments of certain actions, it will be apparent that such descriptions are merely for convenience and that such actions in fact result from a machine device, computing device, processing device, processor, controller, or other device or machine executing the firmware, software, routines, or instructions.
In the claims and specification of the present application, a module for performing a specified function or a module described using functional features is intended to encompass any way of performing that function, such as: a combination of circuit elements that performs that function, software for performing or implementing that function, or any form of software, firmware, code or combination thereof with appropriate circuitry. The functions provided by the various modules are combined together in the manner claimed and it should therefore be considered that any module, component, element which may provide such functions is equivalent or equivalent to the module defined in the claims.
This specification discloses the application using examples in which one or more examples are described or illustrated in the specification and drawings. Each example is provided by way of explanation of the application, not limitation of the application. In fact, it will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the scope or spirit of the application. For instance, features illustrated or described as part of one embodiment, can be used with another embodiment to yield a still further embodiment. It is therefore intended that the present application cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents. The above description is only a specific embodiment of the present application, but the scope of the present application is not limited thereto, and any technical solutions that can be obtained by a person skilled in the art through logic analysis, reasoning or limited experiments based on the concepts of the present application, or easily conceivable variations or alternatives thereof, should be covered by the scope of the present application.

Claims (20)

1. A file access control method, comprising:
when monitoring access operation on a target file, acquiring a locking state and an exclusive condition of the target file; and
judging whether the target file is allowed to be accessed or not according to the locking state and the exclusive condition;
wherein if the locked state is unlocked and the exclusive condition is satisfied, access to the target file is permitted.
2. The file access control method according to claim 1, characterized in that:
firstly, judging the locking state and then judging the exclusive condition; wherein,
if the locking state is locked, not allowing to access the target file; and/or
If the locked state is not locked but does not satisfy the exclusive condition, access to the target file is not allowed.
3. The file access control method according to claim 1, characterized in that:
the target file and other files related to the target file form a file cluster based on the association relationship, wherein the target file and the other files comprise files or folders in forms; and the other files in the file clusters have the same locking state and exclusive condition with the target file; and
and when the target file is operated, performing corresponding operation on the other files in the file cluster according to the association relation.
4. The file access control method according to claim 1, characterized in that:
and judging whether the current content of the target file is consistent with the content stored in the target file at the previous time according to the information included in the exclusive condition, thereby determining whether the exclusive condition is met.
5. The file access control method according to claim 4, characterized in that:
the exclusive condition comprises a direct condition, and the direct condition is configured as information which can be directly used for judging whether the current content of the target file is consistent with the content stored in the target file at the previous time; and/or
The exclusive condition includes an indirect condition configured to be usable for acquiring the direct condition.
6. The file access control method according to claim 5, characterized in that:
the direct condition includes a version number of the file;
comparing the version number of the target file with the version number in the exclusive condition; wherein,
if the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file;
if the version number of the target file is smaller than the version number in the exclusive condition, judging that the target file needs to be updated; and
and if the version number of the target file is greater than the version number in the exclusive condition, judging that an error occurs.
7. The file access control method according to claim 5, characterized in that:
the indirect condition comprises a communication mode of a previous visitor, and the indirect condition is used for communicating with the previous visitor according to the communication mode of the previous visitor in the exclusive condition so as to obtain a direct condition for comparing whether the current content of the target file is consistent with the content stored in the previous time of the target file from the previous visitor; and/or
The indirect condition comprises an obtaining mode of a previous saved version, and the previous saved version is obtained according to the obtaining mode of the previous saved version in the exclusive condition so as to update the target file.
8. The file access control method according to claim 1, characterized in that:
and after the target file is accessed, completing the operation before unlocking, updating the exclusive condition, and modifying the locking state into non-locking.
9. The file access control method according to claim 8, characterized in that:
the pre-unlocking operation comprises one or more of the following operations: closing the target file; saving the target file; uploading the target file stored this time to a server; uploading a folder associated with the target file to a server; and carrying out corresponding operation on the file cluster to which the target file belongs and other files included in the file cluster.
10. A file access control system comprising a client, the client comprising:
the relay lock logic module is configured to acquire a locking state and an exclusive condition of a target file when monitoring an access operation on the target file, and judge whether to allow the target file to be accessed according to the locking state and the exclusive condition; and
the access intercepting module is configured to intercept or release the access operation on the target file according to the judgment result of the relay lock logic module;
wherein the power lock logic module is further configured to enable access to the target file when the locked state is unlocked and the exclusive condition is satisfied.
11. The file access control system of claim 10, wherein the client further comprises:
the relay lock service detection module is configured to detect whether the relay lock logic module operates normally; and/or
An access monitoring module configured to monitor an access operation to the target file.
12. The file access control system according to claim 10, further comprising:
a server configured to be able to save a lock state and an exclusive condition of the target file;
the power lock logic module is in communication connection with the server and is configured to obtain the locked state and exclusive condition of the target file from the server.
13. The file access control system according to claim 10, wherein:
the relay lock logic module is further configured to determine the locking state first and then determine the exclusive condition; wherein,
if the locking state is locked, not allowing to access the target file; and/or
If the locked state is not locked but does not satisfy the exclusive condition, access to the target file is not allowed.
14. The file access control system according to claim 10, wherein:
the target files and other files related to the target files form a file cluster based on the association relationship; wherein the form of the target file and the other files comprises a file or a folder; and the other files in the file clusters have the same locking state and exclusive condition with the target file; and
the client is configured to perform corresponding operations on the other files in the file cluster according to the association relation when the target file is operated.
15. The file access control system according to claim 10, wherein:
the relay lock logic module is further configured to determine whether the current content of the target file is consistent with the previously saved content of the target file according to information included in the exclusive condition, so as to determine whether the exclusive condition is met; wherein,
the exclusive condition includes one or more of the following information: the version number of the file; a hash value of the file; the previous modification time of the file; a characteristic value of the file; the communication mode of the previous visitor of the file; and obtaining the last saved version of the file.
16. The file access control system of claim 15, wherein:
the relay lock logic module is further configured to compare the version number of the target file with the version number in the exclusive condition, and determine whether the current content of the target file is consistent with the previously stored content of the target file; wherein,
if the version number of the target file is the same as the version number in the exclusive condition, judging that the current content of the target file is consistent with the previously stored content of the target file;
if the version number of the target file is smaller than the version number in the exclusive condition, judging that the target file needs to be updated; and
and if the version number of the target file is greater than the version number in the exclusive condition, judging that an error occurs.
17. The file access control system of claim 15, wherein:
the relay lock logic module is further configured to communicate with a previous visitor in the exclusive condition according to a communication mode of the previous visitor so as to compare whether the current content of the target file is consistent with the previously saved content of the target file; and/or
The relay lock logic module is further configured to acquire the last saved version according to an acquisition manner of the last saved version in the exclusive condition to update the target file.
18. The file access control system according to claim 10, wherein:
the client is further configured to complete pre-unlocking operation after accessing the target file, update the exclusive condition, and modify the locking state to be non-locking; wherein,
the pre-unlocking operation comprises one or more of the following operations: closing the target file; saving the target file; uploading the target file stored this time to a server; uploading a folder associated with the target file to a server.
19. A file access control apparatus comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor is configured to implement the steps of the file access control method according to any one of claims 1-9 when executing the computer program.
20. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, is able to carry out the steps of the file access control method according to any one of claims 1 to 9.
CN202010404031.9A 2020-05-13 2020-05-13 File access control method and system Pending CN113672966A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010404031.9A CN113672966A (en) 2020-05-13 2020-05-13 File access control method and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010404031.9A CN113672966A (en) 2020-05-13 2020-05-13 File access control method and system

Publications (1)

Publication Number Publication Date
CN113672966A true CN113672966A (en) 2021-11-19

Family

ID=78537107

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010404031.9A Pending CN113672966A (en) 2020-05-13 2020-05-13 File access control method and system

Country Status (1)

Country Link
CN (1) CN113672966A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114327691A (en) * 2021-12-10 2022-04-12 北京五八信息技术有限公司 Application program processing method, device, equipment and storage medium
CN115794750A (en) * 2023-02-07 2023-03-14 北京卡普拉科技有限公司 Method, device and equipment for controlling opening/closing of asynchronous I/O system file
CN116126477A (en) * 2023-04-04 2023-05-16 支付宝(杭州)信息技术有限公司 Method for accessing TPM in computing device and computing device

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438548B1 (en) * 1999-06-30 2002-08-20 International Business Machines Corporation Method of and system for managing documents in a bandwidth constrained environment
CN102016872A (en) * 2008-05-08 2011-04-13 微软公司 Controlling access to documents using file locks
CN102110083A (en) * 2009-12-28 2011-06-29 北大方正集团有限公司 Client device and method for supporting online and offline editing of document
US20140279846A1 (en) * 2013-03-13 2014-09-18 CoralTree Inc. System and method for file sharing and updating

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438548B1 (en) * 1999-06-30 2002-08-20 International Business Machines Corporation Method of and system for managing documents in a bandwidth constrained environment
CN102016872A (en) * 2008-05-08 2011-04-13 微软公司 Controlling access to documents using file locks
CN102110083A (en) * 2009-12-28 2011-06-29 北大方正集团有限公司 Client device and method for supporting online and offline editing of document
US20140279846A1 (en) * 2013-03-13 2014-09-18 CoralTree Inc. System and method for file sharing and updating

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114327691A (en) * 2021-12-10 2022-04-12 北京五八信息技术有限公司 Application program processing method, device, equipment and storage medium
CN115794750A (en) * 2023-02-07 2023-03-14 北京卡普拉科技有限公司 Method, device and equipment for controlling opening/closing of asynchronous I/O system file
CN116126477A (en) * 2023-04-04 2023-05-16 支付宝(杭州)信息技术有限公司 Method for accessing TPM in computing device and computing device
CN116126477B (en) * 2023-04-04 2023-07-25 支付宝(杭州)信息技术有限公司 Method for accessing TPM in computing device and computing device

Similar Documents

Publication Publication Date Title
US11500897B2 (en) Allocation and reassignment of unique identifiers for synchronization of content items
US11455380B2 (en) Chain-of-custody of digital content in a database system
KR101311145B1 (en) Security in peer to peer synchronization applications
US10530854B2 (en) Synchronization of permissioned content in cloud-based environments
US9792294B2 (en) Using byte-range locks to manage multiple concurrent accesses to a file in a distributed filesystem
US9805056B2 (en) Synchronizing file updates between two cloud controllers of a distributed filesystem
US10169367B2 (en) Managing opportunistic locks in a distributed file system
US9646022B2 (en) Distributed change notifications for a distributed filesystem
CN113672966A (en) File access control method and system
CN111796968A (en) Database transaction guaranteed submission
JP2020537212A (en) Workflow function of the content management system implemented by the client device
WO2019047976A1 (en) Network file management method, terminal and computer readable storage medium
CN105453127A (en) Method and system for document synchronization in a distributed server-client environment
CN112084186A (en) Splitting and merging storage
CN113094754B (en) Big data platform data modification system and modification, response, cache and verification method
WO2024032262A1 (en) Object storage service configuration method and apparatus based on cloud computing technology
JP2023547439A (en) Intent tracking for asynchronous behavior
CN112084187A (en) Splitting and merging of storage

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20240428

Address after: Room 401, Building 1, Lane 500, Zhangheng Road, Pudong New Area, Shanghai, October 2012

Applicant after: Shanghai Yijing Network Technology Co.,Ltd.

Country or region after: China

Address before: Room 401, building 1, Lane 500, zhangheng Road, Pudong New Area, Shanghai, 201203

Applicant before: SHANGHAI YICUN NETWORK TECHNOLOGY Co.,Ltd.

Country or region before: China