File system event processing method and apparatus based on intelligent filtering rules

Abstract

The application discloses a kind of file system event processing method and device based on intelligent filtering rule, by obtaining the file system original event of monitoring directory and carrying out cross-platform standardization processing, extract the event characteristic vector of four dimensions of time, file, process, path, construct the rule base including editor, compiler, version control tool and other software operation mode, mode matching is carried out to event sequence and confidence is calculated, filter strategy type is determined based on matching result and corresponding processing is executed, while system parameters are dynamically optimized by statistical analysis.The application solves the technical problems that the existing file monitoring system event is serious, false triggering frequently, can intelligently distinguish effective file operation and temporary intermediate operation, greatly reduces invalid synchronous trigger, accuracy is improved from 60-70% of traditional scheme to 95% or more, reduces more than 90% of invalid event processing.

Description

Technical Field

[0001] This invention belongs to the field of computer file system monitoring and file synchronization technology, specifically involving intelligent identification, filtering and processing technology for file system events, and particularly involving an intelligent filtering method for file system events based on multi-dimensional feature analysis and operation pattern recognition. Background Technology

[0002] Current mainstream file synchronization and monitoring systems primarily rely on file system event notification mechanisms provided by the operating system, such as inotify for Linux and ReadDirectoryChangesW for Windows. Typical implementation schemes include: inotify-based monitoring schemes, where applications register monitoring directories and receive basic events such as CREATE, MODIFY, DELETE, and MOVE when files change, then trigger corresponding synchronization operations based on the events; static filtering rule schemes, which filter events through predefined file extension blacklists (such as *.tmp, .swp, .log) or whitelists to avoid processing temporary files; and time-delay-based batch processing schemes, which set fixed delay time windows to merge multiple events within a short period of time.

[0003] The existing technology has the following limitations: First, there is a serious problem of event redundancy. Existing systems generate a large number of redundant events when handling common file operations. For example, when a user edits a file using Vim, multiple events are actually generated, such as creating a swap file (.swp), creating a backup file (.txt~), modifying the original file, and deleting a temporary file. However, the user's true intention is only to modify one file, and a simple save operation may generate more than 10 file system events. Many applications use an atomic operation pattern of "write temporary file → rename" to ensure data consistency, which generates multiple events such as creating a temporary file, writing data, and renaming / overwriting. During code compilation, a large number of intermediate files (.o, .class, .pyc, etc.) are generated. These files are irrelevant to source code synchronization, and the compilation of a single project may generate thousands of irrelevant file events.

[0004] Secondly, static filtering rules have shortcomings. Different development environments and software tools have their own temporary file patterns, requiring extensive manual configuration. A complete development environment may need to configure hundreds of filtering rules. Simple filename matching cannot understand the operational context. For example, a user creating a formal file named test.tmp might be misclassified as a temporary file, while important configuration files for certain applications might be incorrectly filtered due to their file extensions. Static rules cannot adapt to new software tools or changes in user behavior. Every time a new development tool or application is introduced, its file operation patterns need to be re-examined and rules added manually. The rule base needs continuous maintenance and updates, resulting in high labor costs.

[0005] Third, there is a lack of operational semantic understanding. Current technology can only identify low-level file system events and cannot understand high-level operational semantics. It cannot distinguish between a user's "final save operation" and "intermediate editing process"; the system only sees a series of discrete file events and cannot understand that these events together constitute a complete user operation. It cannot identify the process type and behavior pattern that generates the events, and cannot distinguish whether the file operation is generated by the editor, compiler, or user script. It cannot analyze the inherent logical relationships between event sequences; multiple time-related and logically related events are treated as independent events, and the overall operational pattern they constitute cannot be identified.

[0006] These technical issues lead to serious performance and user experience problems in practical applications. In development environment synchronization scenarios, every time a developer saves a .java file, the IDE simultaneously updates .class files and .iml configuration files. Compilation generates numerous intermediate files such as .o, .so, and .a files, and version control tools frequently update files in the .git directory. Over 95% of the file events generated by these operations do not need to be synchronized. In document collaboration scenarios, Office software generates numerous temporary files starting with ~$, and the auto-save function frequently triggers file modification events. What truly needs to be synchronized is only the final saved document version.

[0007] Therefore, there is an urgent need for a file system event handling technology that can intelligently identify operation intentions, adaptively adjust filtering strategies, filter with high accuracy, be cross-platform compatible, and be lightweight. Summary of the Invention

[0008] The purpose of this invention is to provide a file system event processing method and apparatus based on intelligent filtering rules, which solves the technical problems of low event monitoring efficiency and frequent false triggering in existing file monitoring systems.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A file system event processing method based on intelligent filtering rules includes: acquiring raw file system events from a monitored directory; performing cross-platform event mapping and path standardization on the raw file system events to obtain standardized event data; extracting features from the standardized event data, including time-dimensional features, file-dimensional features, process-dimensional features, and path-dimensional features, to obtain a multi-dimensional event feature vector; constructing operation pattern rules containing triggering conditions, matching priorities, and processing actions based on software operation behavior pattern information, to obtain an operation pattern rule library; performing pattern matching on event sequences and calculating matching confidence based on the multi-dimensional event feature vector and the operation pattern rule library, to obtain pattern matching results; determining the filtering strategy type based on the pattern matching results and performing corresponding filtering processing on the events, outputting event filtering decision results; and analyzing the filtering effect and dynamically adjusting time window parameters and rule weight parameters based on the event filtering decision results and runtime statistics, to obtain optimized system parameters.

[0010] Furthermore, cross-platform event mapping and path standardization processing are performed on the original events of the file system to obtain standardized event data, including: obtaining the event type, timestamp, and file path of the original events of the file system; mapping the event types of different operating systems to a unified internal event type to obtain the mapped event type; performing path separator unification and absolute path conversion processing on the file paths in the original events of the file system to obtain a normalized path; and generating the standardized event data based on the mapped event type, the normalized path, and the timestamp.

[0011] Furthermore, the extraction of time dimension features includes: calculating the time offset of the event occurrence time relative to the monitoring start time based on the timestamps in the standardized event data to obtain absolute time features; calculating the time interval between adjacent events, identifying fast continuous events with time intervals less than a preset threshold to obtain relative time features; and statistically analyzing the frequency and density of events occurring within a preset time window to identify periodic events and sudden events to obtain time sequence pattern features.

[0012] Furthermore, extracting file dimension features includes: parsing the file paths in the standardized event data to extract file names, extensions, and directory levels to obtain path parsing features; performing pattern recognition on the file names to identify temporary file suffixes, temporary file prefixes, and intermediate compilation file patterns to obtain file name pattern features; and obtaining file size and attribute change information to obtain file attribute features.

[0013] Furthermore, extracting process-dimensional features includes: obtaining the process identifier and process name that trigger the original event of the file system to obtain basic process information; based on a preset mapping table between process names and process types, performing type identification on the process names to identify editor processes, compiler processes, version control tool processes, and office software processes to obtain process type features; and counting the number of operations and the set of files operated by the same process within a preset time window to obtain process behavior features.

[0014] Furthermore, based on software operation behavior pattern information, operation pattern rules including triggering conditions, matching priorities, and processing actions are constructed to obtain an operation pattern rule library. This includes: editor operation pattern rules based on editor software file operation sequence information, containing event sequence triggering conditions for swap file creation, original file modification, and swap file deletion, with the processing action of these editor operation pattern rules set to only synchronize the last modification of the original file; compiler operation pattern rules based on compiler software file operation sequence information, containing intermediate file batch creation triggering conditions, with the processing action of these compiler operation pattern rules set to delayed synchronization; and version control operation pattern rules based on version control tool file operation sequence information, containing event sequence triggering conditions for lock file creation, lock file modification, and lock file renaming. The processing action of the version control operation mode rule is set to only synchronize the final state; based on the file operation sequence information of the office software, an office software operation mode rule containing temporary file prefix mode triggering conditions is constructed, and the processing action of the office software operation mode rule is set to filter temporary files; based on the file operation sequence information of application atomic writes, an atomic write operation mode rule containing event sequence triggering conditions of temporary file creation, data writing, and renaming overwrite is constructed, and the processing action of the atomic write operation mode rule is set to wait for the renaming to complete before synchronizing; the editor operation mode rule, the compiler operation mode rule, the version control operation mode rule, the office software operation mode rule, and the atomic write operation mode rule are sorted and stored according to matching priority to obtain the operation mode rule library.

[0015] This invention also provides two pattern matching technical solutions: The first approach involves performing pattern matching on the event sequence and calculating the matching confidence score based on the multi-dimensional event feature vector and the operation pattern rule base to obtain the pattern matching result. This includes: representing the multi-dimensional event feature vector as a set, converting the features of each event into a feature index set, and taking the union of the feature index sets of all events in the event sequence as the complete set to obtain the event feature set; representing each rule in the operation pattern rule base as a coverage set, determining the feature index set that each rule can explain, and obtaining the rule coverage set; and performing pairwise compatibility judgments on the rules in the operation pattern rule base, based on the rule coverage... A rule compatibility graph is constructed using the intersection of cover sets and semantic conflict relationships, where nodes represent rules and edges represent conflict relationships between rules. Based on the complete set of event features, the rule cover set, and the rule compatibility graph, the pattern matching problem is transformed into a minimum set cover problem with compatibility constraints. A parameterized algorithm is used to solve for the minimum rule subset that satisfies both the coverage integrity and compatibility constraints, obtaining the optimal rule set. Based on the optimal rule set, rule matching is performed on each event in the event sequence, and the explanation score of each rule for the event is calculated. The rule with the highest explanation score is taken as the matching rule for the event, obtaining the pattern matching result.

[0016] The second approach, based on the multi-dimensional event feature vector and the operation pattern rule base, performs pattern matching on the event sequence and calculates the matching confidence to obtain the pattern matching result. This includes: encoding each dimension of the multi-dimensional event feature vector using a linear feedback shift register (LFP) to encode the time dimension, file dimension, process dimension, and path dimension features into fixed-length binary state values, and combining these binary state values ​​to obtain the event feature encoding; and performing rolling hash calculation on the event feature encoding based on a preset sliding window size, utilizing the shift characteristics of the LFP to achieve incremental hashing during window sliding. The process involves updating the window hash value, generating a pattern signature for each rule in the operation pattern rule base, calculating the signature hash value based on the linear feedback shift register encoding of the rule's typical event sequence, and setting a matching tolerance threshold to obtain a pattern signature base. Based on the window hash value and the pattern signature base, the Hamming distance between the window hash value and each pattern signature is calculated. Rules corresponding to pattern signatures with a Hamming distance less than the matching tolerance threshold are selected as candidate matching rules to obtain a candidate matching rule set. The matching confidence score is calculated for the rules in the candidate matching rule set, and the rule with the highest matching confidence score is selected as the final matching rule to obtain the pattern matching result.

[0017] Further, based on the pattern matching results, the filtering strategy type is determined and corresponding filtering processing is performed on the events, outputting the event filtering decision results. This includes: determining the event filtering strategy type based on the processing actions of the matching rules in the pattern matching results; the filtering strategy type includes direct filtering, delayed processing, conditional triggering, immediate triggering, and batch triggering; for events whose filtering strategy type is delayed processing or conditional triggering, the events are added to an event waiting queue, and the event information, the time of adding to the queue, and the waiting timeout are recorded to obtain a queue of events to be decided; correlation analysis is performed on the events in the queue of events to be decided to identify events generated by the same process. The event association graph is constructed by analyzing multiple operation events on the same file and related operation events in the same directory, and establishing causal dependencies between these events. Based on the event association graph, the indicative start and end events of the event sequence are identified, and it is determined whether the operation sequence has been completed, resulting in an operation integrity judgment result. Based on the filtering strategy type, the event association graph, and the operation integrity judgment result, events of the direct filtering type are ignored, events of the immediate trigger type are synchronously triggered, events of the delayed processing type whose operations have been completed are synchronously triggered, and events whose operations have not been completed continue to wait, resulting in the event filtering decision result.

[0018] Furthermore, the pattern signature library is updated through adaptive signature learning, including: collecting the event feature encodings of event sequences and the corresponding pattern matching results, counting the number of matches and the matching accuracy of each rule to obtain rule matching statistics; for rules with a matching accuracy higher than a preset accuracy threshold, using the linear feedback shift register encoding of the successfully matched event sequence as a positive sample, calculating the average Hamming distance between the positive sample and the existing signatures, and updating the existing signatures by weighted average if the average Hamming distance is less than the matching tolerance threshold; for rules with a matching accuracy lower than the preset accuracy threshold, analyzing the event sequence features of mismatched events, adjusting the matching tolerance threshold of the corresponding signature in the pattern signature library or updating the signature hash value to obtain the updated pattern signature library.

[0019] This invention also provides a file system event processing device based on intelligent filtering rules, comprising: an event acquisition module for acquiring raw file system events of a monitored directory, performing cross-platform event mapping and path standardization on the raw file system events to obtain standardized event data; a feature extraction module for extracting features from the standardized event data, extracting time-dimensional features, file-dimensional features, process-dimensional features, and path-dimensional features to obtain a multi-dimensional event feature vector; a rule base management module for constructing operation pattern rules containing triggering conditions, matching priorities, and processing actions based on software operation behavior pattern information to obtain an operation pattern rule base; a pattern matching module for performing pattern matching on event sequences and calculating matching confidence based on the multi-dimensional event feature vector and the operation pattern rule base to obtain a pattern matching result; an intelligent filtering module for determining the filtering strategy type based on the pattern matching result and performing corresponding filtering processing on the events, outputting event filtering decision results; and a parameter optimization module for analyzing the filtering effect and dynamically adjusting time window parameters and rule weight parameters based on the event filtering decision results and running statistics to obtain optimized system parameters.

[0020] The beneficial effects of this invention are: First, through a multi-dimensional event feature analysis framework, a comprehensive feature analysis based on four dimensions—time, file, process, and path—is proposed for the first time. This approach can deeply understand the semantics and context of file operations, improving accuracy from 60-70% in traditional solutions to over 95% and reducing the false positive rate by over 80%.

[0021] Secondly, by establishing a rule base system that covers the operation modes of mainstream software, it is possible to accurately identify the file operation behavior of software such as editors, compilers, and version control tools, reduce more than 90% of invalid synchronization triggers, and avoid file conflicts caused by synchronization triggers during operation.

[0022] Third, through the event time sequence correlation analysis algorithm, it is possible to identify logically related event sets from discrete file system events, accurately identify atomic operations and batch operations, and avoid misjudging intermediate steps of an operation as independent operations.

[0023] Fourth, through the parameter adaptive mechanism of statistical learning, the system can automatically adapt to the environment and continuously optimize, significantly reducing configuration and maintenance costs and achieving intelligent operation with zero or low configuration.

[0024] Fifth, it provides an optimization scheme based on set covering theory, which selects the minimum optimal rule set through global optimization, and achieves significant accuracy improvement and rule simplification with slight time overhead.

[0025] Sixth, it provides a high-speed solution based on LFSR encoding, which is more than 30 times faster than traditional solutions, reduces memory usage by more than 90%, and supports real-time streaming processing of 10,000+ events / s. Attached Figure Description

[0026] Figure 1 This is a detailed flowchart of an embodiment of the present invention; Figure 2 This is a device architecture diagram of an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0028] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Example

[0029] like Figure 1 As shown, this embodiment provides a file system event processing method based on intelligent filtering rules, including: acquiring original file system events of a monitored directory; performing cross-platform event mapping and path standardization on the original file system events to obtain standardized event data; extracting features from the standardized event data, including time dimension features, file dimension features, process dimension features, and path dimension features, to obtain a multi-dimensional event feature vector; constructing operation pattern rules containing triggering conditions, matching priorities, and processing actions based on software operation behavior pattern information, to obtain an operation pattern rule library; performing pattern matching on event sequences and calculating matching confidence based on the multi-dimensional event feature vector and the operation pattern rule library, to obtain pattern matching results; determining the filtering strategy type based on the pattern matching results and performing corresponding filtering processing on the events, outputting event filtering decision results; and analyzing the filtering effect and dynamically adjusting time window parameters and rule weight parameters based on the event filtering decision results and running statistics, to obtain optimized system parameters.

[0030] S1: Event Collection and Standardized Processing The system obtains raw file system events through file monitoring interfaces provided by the operating system (such as inotify on Linux, ReadDirectoryChangesW on Windows, and FSEvents on macOS). Each raw event contains basic information such as event type (CREATE, MODIFY, DELETE, MOVED_FROM, MOVED_TO, ATTRIB, etc.), timestamp accurate to milliseconds, the complete path of the changed file, and a cookie identifier used to associate the move operation. Simultaneously, the system also obtains extended context information such as the process ID, process name, and executable file path that triggered the event, as well as file attribute information such as file size, permissions, owner, and modification time.

[0031] When standardizing the acquired raw events, the event types from different operating systems are first mapped to a unified internal event type. For example, Linux inotify's IN_CREATE, Windows' FILE_ACTION_ADDED, and macOS FSEvents' kFSEventStreamEventFlagItemCreated are uniformly mapped to the internal CREATE event type, thereby eliminating cross-platform event semantic differences. Then, file paths are standardized, unifying path separators (converting Windows backslash \ to forward slash / ), converting relative paths to absolute paths, handling symbolic links and path aliases, and normalizing path case according to file system characteristics (e.g., Windows is case-insensitive, Linux is case-sensitive). Finally, the timestamp format and precision are unified, a global time sequence relationship for events is established, duplicate event notifications are identified and merged, and events generated by the monitoring system's own operations are filtered.

[0032] To improve processing efficiency, the system employs a high-efficiency circular buffer to store raw events, supporting a concurrent mode with multiple producers (monitoring threads) and multiple consumers (processing threads), enabling lock-free or low-lock contention concurrent access. The buffer capacity can be dynamically adjusted to adapt to different event frequencies, and high-water mark and low-water mark settings control backpressure, implementing a reasonable event discarding strategy in extreme cases. The system also supports batch reading and batch processing of events, reducing the overhead of thread synchronization and context switching.

[0033] S2: Multidimensional Feature Extraction Multi-dimensional feature extraction is performed on standardized event data, including features in four aspects: time dimension, file dimension, process dimension, and path dimension.

[0034] In terms of time-dimensional feature extraction, the system records the occurrence time (timestamp) of events, calculates the time offset of events relative to the monitoring start time, and identifies the time period in which events occur (e.g., day / night, working hours / non-working hours). By calculating the time interval between adjacent events, it identifies fast-moving consecutive events (events with a time interval of less than 100 milliseconds) and time-clustered event clusters. By statistically analyzing the frequency and density of events occurring within a preset time window, it identifies periodic events (e.g., scheduled backups) and sudden events (a large number of events in a short period of time), calculates the total duration of related event sequences, identifies long-term and short-term operations, and determines whether the operation has been completed.

[0035] In terms of file-level feature extraction, the system performs deep parsing of file paths, extracting filenames, extensions, and base names; parsing directory paths and directory levels; identifying special directories (such as .git, .svn, node_modules, __pycache__, etc., version control and build directories); and identifying temporary directories (such as / tmp, / var / tmp, %TEMP%). It performs pattern recognition on filenames, identifying temporary file extensions (such as .tmp, .swp, .swo, .bak, etc.), temporary file prefixes (such as $, #, .~lock., etc.), version numbers, timestamps, random strings, and other patterns; and identifying intermediate compilation files (such as .o, .class, .pyc, etc.). Simultaneously, it records the current file size, calculates the amount and rate of change in file size, identifies large and small files, identifies abnormal changes in file size, and tracks changes in file permissions, owner, modification time, and access time.

[0036] In terms of process-level feature extraction, the system extracts process IDs and process names, obtains the executable file paths of processes, and identifies the parent processes of processes. It establishes a mapping table from process names to process types, identifying editor processes (such as Vim, Emacs, Code, Sublime Text, etc.), compiler processes (such as GCC, G++, javac, Python, etc.), version control tools (such as Git, SVN, etc.), office software (such as Word, Excel, LibreOffice, etc.), system tools, and background services. By statistically analyzing the number of operations performed by the same process within a time window, it identifies the file access patterns of processes, associates processes with the sets of files they operate on, and forms process behavior characteristics.

[0037] In terms of path-dimensional feature extraction, the system identifies source code directories (including feature files such as .git, Makefile, and package.json), build output directories (such as build, dist, target, and bin), dependency library directories (such as node_modules, vendor, and lib), documentation directories (such as docs and doc), and configuration directories (such as .config and config). Based on the directory structure and feature files, it infers the project type, such as front-end projects (including package.json and webpack.config.js), Java projects (including pom.xml and build.gradle), Python projects (including setup.py and requirements.txt), and C / C++ projects (including Makefile and CMakeLists.txt). It also identifies related files in the same directory, the correspondence between source files and compiled artifacts, and the association between configuration files and data files.

[0038] All extracted features are combined to form a multi-dimensional event feature vector, providing a rich information foundation for subsequent pattern matching.

[0039] S3: Build an operational mode rule base Based on software operation behavior pattern information, an operation pattern rule base is constructed, which includes triggering conditions, matching priorities, and processing actions. Each rule in the rule base includes elements such as rule name and description, triggering conditions (file mode, process mode, event sequence mode), matching priority, processing actions (filtering, delay, marking, etc.), and confidence weight.

[0040] For editor software, based on the editor's file operation sequence information, rules are constructed to define editor operation patterns that include event sequence triggering conditions for swap file creation, original file modification, and swap file deletion. For example, the Vim editor pattern rules identify a typical event sequence: CREATE event.swp (swap file creation) → MODIFY event.txt (original file modified multiple times) → MODIFY event.swp (swap file update) → DELETE event.swp (swap file deletion). Matching conditions include filename pattern matching ..swp or ..swo, process name being vim or vi, and time window within 2 seconds. The processing action of these editor operation pattern rules is set to only synchronize the last modification of the original file, ignoring all operations on the .swp file. Similarly, rules are constructed for Emacs to identify the sequence of ~backup file → #autosave# file → original file saving, and rules are constructed for VSCode to identify the operation pattern of .code-workspace temporary files.

[0041] For compiler software, compiler operation pattern rules are constructed based on the compiler software's file operation sequence information, including trigger conditions for batch creation of intermediate files. For example, the C / C++ compilation pattern rules identify batch creation patterns of intermediate files such as .o, .so, and .a, with matching conditions including process names of gcc, g++, and clang, batch CREATE events involving *.o, .so, and .a files, and a time window of 10 seconds. The processing action of these compiler operation pattern rules is set to delayed synchronization, waiting for compilation to complete before processing. Similarly, rules are constructed for Java compilation to identify patterns where .class files are modified along with .java files, rules for Python compilation to identify patterns where the __pycache__ directory and .pyc files are generated, and rules for front-end build tools to identify batch operations on the node_modules, dist, and build directories.

[0042] For version control tools, based on the file operation sequence information of the version control tool, version control operation pattern rules are constructed, which include event sequence triggering conditions for lock file creation, lock file modification, and lock file renaming. For example, Git operation pattern rules identify typical index update sequences: The code `CREATE .git / index.lock→MODIFY .git / index.lock→MOVED_FROM .git / index.lock→MOVED_TO .git / index` matches files whose paths contain `.git / ` and whose filenames contain `.lock`. This sets the version control operation mode rule to only synchronize the final state, specifically the final state of `.git / index`, ignoring the `.lock` file. Similarly, rules are created for SVN to recognize temporary file patterns in the `.svn` directory.

[0043] For office software, based on file operation sequence information, rules for office software operation modes are constructed, including trigger conditions for temporary file prefix patterns. For example, MS Office mode rules identify temporary files starting with ~$ and .tmp file patterns, and set the processing action of the office software operation mode rules to filter temporary files. Rules for recognizing .~lock file locking patterns are constructed for LibreOffice, and rules for recognizing temporary cache files such as .pdf and .tmp are constructed for PDF readers.

[0044] For application atomic write operations, based on the file operation sequence information of the application's atomic writes, an atomic write operation pattern rule is constructed, which includes event sequence triggering conditions for temporary file creation, data writing, and renaming overriding. A typical sequence is identified as: CREATE temp_file.tmp → MODIFY temp_file.tmp (write data) → MOVED_FROM temp_file.tmp → MOVED_TO target_file. The processing action of the atomic write operation pattern rule is set to wait for the renaming to complete before synchronizing, ignoring the temporary file.

[0045] The editor operation mode rules, compiler operation mode rules, version control operation mode rules, office software operation mode rules, and atomic write operation mode rules are sorted and stored according to matching priority to obtain the operation mode rule library. The rule library is stored using a readable configuration file format (such as YAML or JSON), supports rule grouping and inheritance, supports rule enabling / disabling, and supports the addition and modification of user-defined rules.

[0046] S4: Pattern Matching and Confidence Calculation Based on the multi-dimensional event feature vector and the operation pattern rule base, the system performs pattern matching on the event sequence and calculates the matching confidence. The system receives the event feature vector as input, traverses the rule base in priority order, performs condition matching on each rule, calculates the matching confidence, selects the best matching rule, and executes the processing action defined by the rule.

[0047] For filename pattern matching, the system supports wildcard matching (*, ?), regular expression matching, exact prefix / suffix matching, and case-sensitive / case-insensitive matching. For event sequence matching, a finite state machine is used for sequence pattern matching, supporting partial and complete sequence matching, event order constraints within the sequence, and time window constraints within the sequence. For multi-condition combination matching, it supports AND, OR, and NOT logical combinations, condition weights and priorities, and calculates a comprehensive matching score.

[0048] To improve matching efficiency, the system establishes a fast index to accelerate rule lookup, uses a caching mechanism to avoid redundant calculations, and employs a short-circuit evaluation strategy. For example, for events that are clearly mismatched (such as file extensions not within the scope of a rule's focus), the detailed matching process for that rule can be quickly skipped.

[0049] The calculation of matching confidence considers multiple factors: feature matching degree (the degree to which event features match the rule requirements), sequence completeness (whether the event sequence completely matches the pattern defined by the rule), time window compliance (whether the time interval between events meets the rule requirements), and historical accuracy (the accuracy of the rule in historical matches). The final matching confidence is calculated through weighted averages, and matches with confidence scores higher than a preset threshold are considered valid matches.

[0050] S5: Filtering Decisions and Event Handling Based on the pattern matching results, the filtering strategy type is determined and corresponding filtering processing is performed on the events. First, based on the processing actions of the matching rules in the pattern matching results, the filtering strategy type of the events is determined. The filtering strategy types include direct filtering (FILTER), delayed processing (DELAY), conditional triggering (CONDITIONAL), immediate triggering (IMMEDIATE), and batch triggering (BATCH).

[0051] Direct filtering strategies are suitable for explicit temporary files and system files, completely ignoring the event and not triggering any subsequent processing, such as .swp files and files starting with ~$. Delayed processing strategies are suitable for situations requiring observation of subsequent events, adding the event to a waiting queue and processing it after a delay, such as waiting for an atomic write operation to complete. Conditional triggering strategies determine whether to trigger based on subsequent events, suitable for situations requiring a complete sequence for judgment, such as waiting for a group of related events to complete. Immediate triggering strategies are suitable for explicit valid operations, immediately triggering subsequent processing (synchronous operations), such as modifications to source code files. Batch triggering strategies aggregate multiple related events and trigger them in batches, suitable for batch operation scenarios, such as batch synchronizing source file modifications after compilation.

[0052] For events whose filtering strategy type is delayed processing or conditional triggering, the event is added to an event waiting queue, and the event information, the time of addition to the queue, and the waiting timeout are recorded to obtain a queue of events to be decided. A waiting queue record is maintained for each event to be decided, and a maximum waiting time (e.g., 5 seconds) is set. After the timeout, a decision is forced to be made to avoid infinite waiting. Different timeout times are configured according to different scenarios. The system periodically cleans up the records of decided events, releasing memory resources that are no longer needed to prevent the queue from growing indefinitely.

[0053] The system performs correlation analysis on the events in the queue of events to be decided, identifying events generated by the same process, multiple operation events on the same file, and related operation events under the same directory, and constructs causal dependencies between events to obtain an event correlation graph. The system identifies causal dependencies between events, such as the dependency chain of temporary file creation → writing → renaming to the target file, and constructs a directed dependency graph to represent these relationships. Events that are temporally and logically related are aggregated into event clusters, and the event clusters are analyzed and decided upon as a whole, avoiding the need to process each event in the cluster individually.

[0054] Based on the event association graph, the system identifies key start and end events of an event sequence to determine whether the operation sequence is complete, thus obtaining an operation integrity assessment result. For example, the key end event for an editor save operation is the deletion of a swap file, and the end event for a Git index update is renaming a .lock file to a .index file. By identifying these key events, the system can accurately determine whether a complex operation has been completed, avoiding triggering synchronization midway through the operation.

[0055] Based on the filtering strategy type, the event association graph, and the operation integrity judgment result, events of the direct filtering type are ignored, events of the immediate trigger type are synchronously triggered, events of the delayed processing type whose operations have been completed are synchronously triggered, and events whose operations have not been completed continue to wait, thus obtaining the event filtering decision result. The system output decision result includes information such as whether the event should trigger synchronization, the timing of the trigger, and the list of files involved, for use by the file synchronization system.

[0056] S6: Statistical Learning and Parameter Optimization Based on the event filtering decision results and operational statistics, the system analyzes the filtering effect and dynamically adjusts the time window parameters and rule weight parameters. The system records the trigger count of each rule, the usage frequency of each filtering strategy, and the number and proportion of filtered events. It also analyzes frequently occurring filename patterns, frequently triggered file types, and identifies environment-specific file patterns. Furthermore, it calculates the average event processing latency, the average length of the waiting queue, and the average time spent on rule matching. Finally, it records user-manually confirmed synchronization operations, user-cancelled synchronization operations, and user-added custom rules.

[0057] Regarding adaptive adjustment of the time window, the system sets a default time window (e.g., 500 milliseconds) as the initial value based on experience, analyzes the actual time span distribution of the event sequence, and dynamically adjusts the time window size based on statistical results. For example, if statistics show that 95% of the relevant event sequences are completed within 200 milliseconds, the system can shorten the time window to 250 milliseconds, thereby reducing unnecessary waiting time, improving the real-time performance of event processing, and ensuring the accuracy of operation integrity judgment.

[0058] Regarding the adaptive adjustment of rule weights, all rules initially use preset weight values. The system evaluates the effectiveness of each rule by statistically analyzing its accuracy and false positive rate, increasing the weight of rules with high accuracy and decreasing the weight of rules with high false positive rates. The weights are updated periodically (e.g., hourly) based on statistical data. For waiting timeouts, the system adjusts them based on the statistical distribution of operation completion times; for batch trigger thresholds, the system adjusts them based on the actual scale of batch operations.

[0059] The system also features automatic rule base expansion capabilities. It detects high-frequency event patterns not covered by existing rules, extracts common features from these patterns, generates candidate rules, and marks them for verification. After observing these candidate rules for a period, its triggering frequency and effectiveness are statistically analyzed. Once verified, the rules are added to the official rule base. Simultaneously, the system merges rules with similar functions, deletes rules that are rarely triggered or have poor effects, and simplifies overly complex rules, maintaining a streamlined and efficient rule base.

[0060] In terms of anomaly detection, the system detects a sudden surge in unknown file patterns, high-frequency abnormal events (which may be infinite loops or errors), and sudden drops in filtering effectiveness. It reports detected anomalies to the user, suggests that the user check or add new rules, and logs anomalies for subsequent analysis.

[0061] Through the coordinated operation of the above six steps, this invention achieves intelligent file system event processing, which can accurately identify the user's true operational intent, significantly reduce the triggering of invalid events, and improve the overall efficiency and user experience of the file synchronization system. Example

[0062] This embodiment, based on embodiment 1, details the specific implementation of cross-platform event mapping and path standardization processing.

[0063] The process involves performing cross-platform event mapping and path standardization on the original events of the file system to obtain standardized event data. This includes: obtaining the event type, timestamp, and file path of the original events of the file system; mapping the event types of different operating systems to a unified internal event type to obtain the mapped event type; performing path separator unification and absolute path conversion on the file paths in the original events of the file system to obtain a normalized path; and generating the standardized event data based on the mapped event type, the normalized path, and the timestamp.

[0064] S2.1: Obtain raw event information The system obtains raw file system events through platform-specific APIs. On the Linux platform, an inotify instance is created using inotify_init(), monitored directories are added using inotify_add_watch(), and the inotify_event structure is read using the read() system call. This structure contains fields such as wd (watch descriptor), mask (event type mask, such as IN_CREATE, IN_MODIFY, IN_DELETE, IN_MOVED_FROM, IN_MOVED_TO, etc.), cookie (used to associate move events), len (filename length), and name (filename).

[0065] On the Windows platform, the ReadDirectoryChangesW function is used to monitor directory changes. This function returns an array of FILE_NOTIFY_INFORMATION structures. Each structure contains fields such as NextEntryOffset (offset of the next structure), Action (action type, such as FILE_ACTION_ADDED, FILE_ACTION_REMOVED, FILE_ACTION_MODIFIED, FILE_ACTION_RENAMED_OLD_NAME, FILE_ACTION_RENAMED_NEW_NAME, etc.), FileNameLength (filename length), and FileName (filename).

[0066] On the macOS platform, use the FSEvents API to create an event stream, set a callback function through the FSEventStreamCreate function, and receive FSEventStreamEventFlags (event flags, such as kFSEventStreamEventFlagItemCreated, kFSEventStreamEventFlagItemModified, kFSEventStreamEventFlagItemRemoved, etc.) and an array of event paths in the callback function.

[0067] In addition to basic event types, timestamps, and file paths, the system also obtains extended information through platform-specific APIs. On Linux, process information is read from the ` / proc / [pid]` directory to obtain the process name, executable file path, parent process ID, etc. On Windows, processes are enumerated using `Process32First` and `Process32Next`, or detailed process information can be queried using WMI (Windows Management Instrumentation). On macOS, process information is obtained using functions such as `proc_pidpath` and `proc_pidinfo`.

[0068] S2.2: Cross-platform event type mapping The system maps event types from different operating systems to a unified internal event type. It maintains an event type mapping table that maps the native event types of each platform to standard internal event types: CREATE (file creation), MODIFY (file modification), DELETE (file deletion), MOVE_FROM (moving source), MOVE_TO (moving target), and ATTRIB (attribute change).

[0069] The specific mapping relationship is as follows: In Linux inotify, IN_CREATE, in Windows, FILE_ACTION_ADDED, and in macOS, kFSEventStreamEventFlagItemCreated are all uniformly mapped to CREATE. In Linux, IN_MODIFY, in Windows, FILE_ACTION_MODIFIED, and in macOS, kFSEventStreamEventFlagItemModified are all uniformly mapped to MODIFY. In Linux, IN_DELETE, in Windows, FILE_ACTION_REMOVED, and in macOS, kFSEventStreamEventFlagItemRemoved are all uniformly mapped to DELETE. In Linux, IN_MOVED_FROM and in Windows, FILE_ACTION_RENAMED_OLD_NAME are uniformly mapped to MOVE_FROM. In Linux, IN_MOVED_TO and in Windows, FILE_ACTION_RENAMED_NEW_NAME are uniformly mapped to MOVE_TO. In Linux, IN_ATTRIB is uniformly mapped to ATTRIB. For move operations, the system requires special handling to associate the MOVE_FROM and MOVE_TO events. In Linuxinotify, related move events have the same cookie value, and the system associates the two events through the cookie value. In Windows, the FILE_ACTION_RENAMED_OLD_NAME and FILE_ACTION_RENAMED_NEW_NAME events appear adjacently in the FILE_NOTIFY_INFORMATION array, and the system associates them based on their position. In macOS, renaming operations may generate the ItemRenamed flag, and the system needs to combine path information for association.

[0070] S2.3: Path standardization processing The file paths in the original events of the file system are processed to unify path separators and convert absolute paths. First, the path separators are unified by converting the Windows backslash () to a forward slash ( / ), making the path representation consistent across all platforms. For example, the Windows path "C:\Users\test\file.txt" is converted to "C: / Users / test / file.txt".

[0071] The relative path is then converted to an absolute path. On Linux and macOS, the `realpath` function is used to convert a relative path to an absolute path; this function resolves symbolic links and returns a normalized absolute path. On Windows, the `GetFullPathName` function is used to obtain the full path name. For subpaths of the monitored directory, the system concatenates the absolute path of the monitored directory with the relative path in the event to obtain the complete absolute path.

[0072] When handling symbolic links and path aliases, the system needs to resolve symbolic links into actual paths to avoid misinterpreting different path representations of the same file as different files. On Linux, the `readlink` function is used to read the target of a symbolic link, recursively resolving it until the actual file path is obtained. On Windows, the `DeviceIoControl` function, in conjunction with the `FSCTL_GET_REPARSE_POINT` control code, is used to read re-resolution point information.

[0073] Normalize path case according to file system characteristics. On case-insensitive file systems such as Windows and macOS (default configuration), paths are uniformly converted to lowercase to avoid "File.txt" and "file.txt" being considered different files. On case-sensitive file systems such as Linux, the original case of the path is maintained. The system determines whether case normalization is needed by detecting the file system type (such as NTFS, HFS+, ext4, etc.).

[0074] S2.4: Generate standardized event data Based on the mapped event type, the normalized path, and the timestamp, the standardized event data is generated. The standardized event data is represented using a unified data structure and includes the following fields: event_id: A unique identifier for the event, an incrementing sequence number generated by the system. event_type: The mapped standard event type (CREATE, MODIFY, DELETE, MOVE_FROM, MOVE_TO, ATTRIB). timestamp: A timestamp accurate to milliseconds, using Unix timestamp format (the number of milliseconds since January 1, 1970). path: the normalized absolute path of the file process_id: The process ID that triggered the event. process_name: Process name process_path: The full path to the process's executable file. file_size: File size (bytes) file_mode: File permission mode file_owner: The file owner file_mtime: Last modified time of the file Cookie: An identifier used to associate movement operations (only for MOVE_FROM and MOVE_TO events) platform: The platform from which the event originated (Linux, Windows, macOS) The generated standardized event data is placed into an event buffer queue for subsequent feature extraction and pattern matching modules. Through this standardized processing, the system can handle file system events from different operating systems in a unified manner, achieving true cross-platform compatibility. Example

[0075] This embodiment details the process of extracting time dimension features.

[0076] The extraction of time dimension features includes: calculating the time offset of the event occurrence time relative to the monitoring start time based on the timestamps in the standardized event data to obtain absolute time features; calculating the time interval between adjacent events, identifying fast and continuous events with time intervals less than a preset threshold to obtain relative time features; and statistically analyzing the frequency and density of events occurring within a preset time window to identify periodic events and sudden events to obtain time sequence pattern features.

[0077] S3.1: Extracting Absolute Time Features Based on the timestamps in the standardized event data, the time offset of the event occurrence time relative to the monitoring start time is calculated. The system records the monitoring start time (start_time, a Unix timestamp) when monitoring begins. For each event, the time offset time_offset = event.timestamp - start_time is calculated. This offset value represents the relative occurrence time of the event within the monitoring session, in milliseconds.

[0078] The system also identifies the time period characteristics of events. By parsing timestamps and extracting time components such as hours and minutes, it determines whether the event occurred during the day (6:00-18:00) or night (18:00-6:00), and whether it occurred during working hours (Monday to Friday 9:00-18:00). These time period characteristics help identify user work patterns; for example, batch operations at night may be automated scripts or backup tasks, while operations during working hours are more likely to be user-initiated edits.

[0079] Absolute time features also include the location of the event within the day (e.g., morning, afternoon, evening) and within the week (e.g., Monday, weekend), which can be used to identify periodic operating patterns.

[0080] S3.2: Extracting relative time features Calculate the time interval between adjacent events and identify fast, consecutive events with a time interval less than a preset threshold. The system maintains an event time series. For the current event event_i, calculate the time interval between it and the previous event event_{i-1}: interval = event_i.timestamp - event_{i-1}.timestamp.

[0081] Set a preset threshold `threshold_fast` of 100 milliseconds. If `interval < threshold_fast`, then `event_i` is marked as a fast consecutive event. Fast consecutive events typically represent multiple underlying steps of the same high-level operation. For example, in an editor's save operation, steps such as creating a swap file, modifying the original file, and deleting the swap file usually occur consecutively within a very short time.

[0082] The system also calculates the average time interval avg_interval of events and identifies anomalous time intervals by comparing the current interval with the average interval. If the interval is much larger than avg_interval (e.g., more than 3 times the standard deviation), it may indicate the end of one operation sequence and the beginning of another.

[0083] The relative time feature also includes the time span of event clusters. The system aggregates events that are close in time into event clusters and calculates the time span of each event cluster (the time difference from the first event to the last event). Event clusters with short time spans (e.g., less than 1 second) usually correspond to atomic operations or fast editing, while event clusters with long time spans (e.g., more than 10 seconds) may correspond to long-running operations such as compilation or batch processing.

[0084] S3.3: Extracting Temporal Pattern Features The system calculates the frequency and density of events occurring within a preset time window, identifying periodic and sudden events. Multiple time windows are set, such as 1-second, 10-second, 1-minute, and 10-minute windows, and the number of events within each window is counted.

[0085] Event frequency is calculated as frequency = event_count / window_duration, representing the number of events per unit time. Event density is calculated using a sliding window; for each time t, the number of events within the time window [t - window_size, t] is counted, resulting in an event density curve. The peak of the density curve represents the moment of sudden event occurrence.

[0086] When identifying periodic events, the system analyzes the periodic patterns in the timing of the events. Autocorrelation analysis is performed on the event time series to detect the presence of periodic time intervals. For example, if a file modification event occurs every 5 minutes, it might be due to an automatic save or scheduled backup task. The system uses Fast Fourier Transform (FFT) or autocorrelation functions to detect the periodicity of the time series.

[0087] When identifying burst events, the system detects a sudden surge in the number of events within a short period. A burst threshold, `threshold_burst`, is set. If the number of events within a certain time window exceeds `threshold_burst` times the average (e.g., 3 times), a burst event is considered to have occurred. Burst events typically correspond to batch operations, such as code compilation generating a large number of intermediate files, or batch file copying operations.

[0088] The temporal pattern characteristics also include the regularity of event occurrences. The regularity of event occurrences is determined by calculating the standard deviation of the event time intervals. A small standard deviation indicates stable event time intervals, which may be periodic tasks; a large standard deviation indicates irregular event occurrences, which may be random user actions.

[0089] By extracting these time-dimensional features, the system can understand the distribution pattern of events on the timeline and identify different time-series features such as rapid continuous operations, periodic tasks, and sudden batch operations, providing an important basis for subsequent pattern matching. Example

[0090] This embodiment details the process of extracting file dimensional features.

[0091] Extracting file dimensional features includes: parsing the file paths in the standardized event data to extract file names, extensions, and directory levels to obtain path parsing features; performing pattern recognition on the file names to identify temporary file suffixes, temporary file prefixes, and intermediate compilation file patterns to obtain file name pattern features; and obtaining file size and attribute change information to obtain file attribute features.

[0092] S4.1: Extract path parsing features The system parses the file paths in the standardized event data, extracting the filename, extension, and directory level. For a given file path, such as " / home / user / project / src / main.java", the system parses it as follows: Filename extraction: Extract the part after the last path separator from the path to obtain the complete filename "main.java". Further separate the base name and extension, with the base name being "main" and the extension being "java". For files with multiple extensions (such as "archive.tar.gz"), the system extracts the last extension "gz" as the primary extension, while recording the complete extension sequence ["tar", "gz"].

[0093] Directory path extraction: Remove the filename portion from the complete path to obtain the directory path " / home / user / project / src". Calculate the directory hierarchy by counting the number of path separators to determine the directory depth; in this example, the directory hierarchy is 5. Extract the names of each directory level to form the directory sequence ["home", "user", "project", "src"].

[0094] Special directory identification: The system maintains a list of special directories, including version control directories (.git, .svn, .hg), build directories (build, dist, target, bin, out), dependency library directories (node_modules, vendor, lib, libs), temporary directories (tmp, temp, cache), configuration directories (.config, config, conf), and documentation directories (docs, doc, documentation). The system iterates through the directory sequence, checking if it contains any of these special directory names. If the path contains ".git", it is marked as a version control directory; if it contains "node_modules", it is marked as a dependency library directory.

[0095] Temporary directory identification: Check if the directory path begins with a system temporary directory, such as " / tmp" or " / var / tmp" in Linux, the actual path corresponding to "%TEMP%" or "%TMP%" in Windows, and " / var / folders" in macOS. If the file is located in a temporary directory, it is likely a temporary file and should be filtered.

[0096] S4.2: Extract filename pattern features The filenames are subjected to pattern recognition to identify temporary file extensions, temporary file prefixes, and intermediate compilation file patterns. The system maintains multiple filename pattern rule bases. Temporary file extension identification: Checks if the file extension matches the list of temporary file extensions, including .tmp, .temp, .swp, .swo, .swn (Vim swap file series), .bak, .backup, ~ (Unix backup file), .old, .orig, .cache, etc. Regular expressions are used for pattern matching; for example, the regular expression ".*\.sw[az]$" can match all Vim swap files (.swa, .swb, .swc, etc.).

[0097] Temporary file prefix identification: Checks if the filename begins with a temporary file prefix, including ~$ (Microsoft Office temporary files), # (Emacs autosave files), .lock. (LibreOffice lock files), and . (hidden files, often used for temporary or configuration files in Unix systems). For example, the filename "$document.docx" matches the Office temporary file pattern, and the filename "#main.c#" matches the Emacs autosave file pattern.

[0098] Intermediate compilation file pattern recognition: Checks if file extensions match a list of intermediate compilation files, including .o, .obj (object files), .so, .dll, .dylib (dynamic link libraries), .a, .lib (static libraries), .class (Java bytecode), .pyc, .pyo (Python bytecode), and .exe (executable files, which are compilation artifacts in some scenarios). These files are typically intermediate or final products of source code compilation and do not need to be synchronized in source code synchronization scenarios.

[0099] Version number and timestamp pattern recognition: Regular expressions are used to detect whether filenames contain version number patterns (such as "file_v1.2.3.txt", "file-20231215.txt") or timestamp patterns (such as "file_2023-12-15_14-30-00.txt"). These patterns typically indicate automatically generated backup files or snapshot files. Regular expression examples: "._v\d+\.\d+\.\d+." matches the version number pattern, ".\d{8}\d{6}." matches the date and timestamp pattern.

[0100] Random string pattern recognition: Detects whether filenames contain random strings, such as "temp_a3f5b9c2.dat". It uses the regular expression ".[a-f0-9]{8,}." to detect hexadecimal strings with a length of at least 8 characters; these filenames are usually system-generated temporary files.

[0101] Lock file pattern recognition: Detects whether the filename contains lock file identifiers such as "lock" or "lck", or has the extension .lock or .lck. Lock files are used for inter-process synchronization and are usually deleted after the operation is completed, so synchronization is not required.

[0102] S4.3: Extract file attribute features The system retrieves file size and attribute change information to obtain file attribute characteristics. Detailed file attributes are obtained through the file system API. File size characteristics: Records the current file size (in bytes). For the MODIFY event, if the file size before modification is available, calculate the file size change delta_size = new_size - old_size and the change rate change_rate = delta_size / old_size. Size change characteristics help identify the nature of file operations, such as append writes (delta_size > 0 and relatively small), full rewrites (delta_size may be negative or change significantly), truncation operations (delta_size < 0), etc.

[0103] Identify large and small files: Set file size thresholds, such as small_file_threshold = 1KB, large_file_threshold = 10MB. Files smaller than small_file_threshold are marked as small files, which may be configuration files, script files, or temporary files; files larger than large_file_threshold are marked as large files, which may be database files, media files, or archive files.

[0104] File size anomaly detection: For multiple MODIFY events of the same file, the system tracks the trend of file size changes. If the file size fluctuates drastically in a short period of time (e.g., from 10MB to 1KB and then back to 10MB), it may indicate abnormal operation or the creation or deletion of temporary files.

[0105] File permission characteristics: Records the file permission mode (such as Unix rwxrwxrwx or the numeric representation 755) and detects permission changes. Permission changes in ATTRIB events may indicate a change in file role; for example, adding executable permission (chmod +x) may indicate the activation of a script file.

[0106] File owner and group characteristics: Records the file owner's user ID and group ID to detect changes in ownership. Changes in ownership may indicate file transfer or permission adjustments, which require special attention in certain scenarios.

[0107] File timestamp characteristics: In addition to the event occurrence time, the system also records the file's last modified time (mtime), last access time (atime), and state change time (ctime). Comparing the event timestamp with the file's mtime, if there is a significant difference, it may indicate that the event was reported late or that the file timestamp was manually modified.

[0108] File type characteristics: File types are identified by their file extensions or file content (magic number), such as text files, binary files, image files, video files, archive files, etc. Different types of files may be handled differently in synchronization strategies. For example, small changes to binary files may require full synchronization, while text files can use incremental synchronization.

[0109] By extracting these file dimensional features, the system can gain a deeper understanding of the nature, purpose, and operation mode of files, providing key information for accurately identifying temporary files, intermediate files, and formal files that need to be synchronized. Example

[0110] This embodiment details the process of extracting process-dimensional features.

[0111] Extracting process-dimensional features includes: obtaining the process identifier and process name that triggers the original event of the file system to obtain basic process information; based on a preset mapping table between process names and process types, identifying the process names to identify editor processes, compiler processes, version control tool processes, and office software processes to obtain process type features; and counting the number of operations and the set of files operated by the same process within a preset time window to obtain process behavior features.

[0112] S5.1: Obtain basic process information The system retrieves the process identifier and process name that triggered the original file system event. During the event acquisition phase, the system has already obtained the process ID (PID) through platform-related APIs. Based on the PID, the system further obtains detailed process information: Process name retrieval: On Linux, read the ` / proc / [pid] / comm` file to get the process name, or read ` / proc / [pid] / cmdline` to get the complete command line. On Windows, use `Process32First` and `Process32Next` to enumerate processes, or use `OpenProcess` and `GetModuleFileNameEx` to get the process name. On macOS, use the `proc_name` function to get the process name.

[0113] Obtaining the process's executable file path: On Linux, read the target of the symbolic link ` / proc / [pid] / exe` to get the full path of the process's executable file. On Windows, use `GetModuleFileNameEx` or `QueryFullProcessImageName` to get the process path. On macOS, use the `proc_pidpath` function to get the process path.

[0114] Parent process identification: On Linux, read the ` / proc / [pid] / stat` file and parse it to obtain the parent process ID (PPID). On Windows, use `CreateToolhelp32Snapshot` and `Process32First / Process32Next` to obtain a process snapshot and extract the parent process ID. On macOS, use the `proc_pidinfo` function in conjunction with the `PROC_PIDTBSDINFO` flag to obtain the parent process ID. Identifying the parent process helps in understanding the process's startup context; for example, a compiler process started by an IDE may require different handling strategies than a compiler process started manually by the user.

[0115] Process command-line arguments: Obtaining the complete command-line arguments for a process helps to more accurately identify the process's purpose. For example, although "git commit" and "git pull" are both git processes, their operations are different, and these can be distinguished by their command-line arguments.

[0116] S5.2: Process Type Identification Based on a preset mapping table between process names and process types, the process names are identified by type. The system maintains a process type mapping table, mapping common process names to predefined process type categories. Editor process identification: The mapping table contains the names of editor processes such as vim, vi, nvim, emacs, nano, gedit, kate, code (Visual Studio Code), sublime text, atom, notepad++, and notepad, mapping them to the "EDITOR" type. File operations generated by editor processes often involve a large number of temporary files and swap files, requiring special filtering rules.

[0117] Compiler process identification: The mapping table contains the names of compiler and interpreter processes such as gcc, g++, clang, clang++, cc, c++, javac, java, python, python3, ruby, perl, node, go, rustc, and cargo, mapping them to the "COMPILER" type. Compiler processes generate a large number of intermediate files and compilation artifacts, which typically do not require synchronization.

[0118] Version control tool process identification: The mapping table contains the process names of version control tools such as git, svn, hg (Mercurial), cvs, and bzr, mapping them to the "VCS" (Version Control System) type. Version control tools generate a large number of temporary files and lock files when operating on directories such as .git and .svn, which need to be identified and filtered.

[0119] Office software process identification: The mapping table contains the process names of office software such as WinWord (Microsoft Word), Excel, PowerPNT (PowerPoint), soffice (LibreOffice), and ooffice (OpenOffice), mapping them to the "OFFICE" type. Office software generates numerous temporary files (such as files starting with ~$) when editing documents, which need to be filtered.

[0120] Build tool process identification: The mapping table contains the process names of build tools such as make, cmake, gradle, maven, ant, npm, yarn, and webpack, and maps them to the "BUILD" type. Build tools generate a large number of intermediate and dependency files during execution, requiring delayed synchronization or batch processing.

[0121] System tools and background services identification: The mapping table contains system tools such as rsync, scp, cp, mv, rm, as well as various background service processes, which are mapped to the "SYSTEM" type. Operations of system tools are usually explicitly initiated by the user and require immediate synchronization; operations of background services may require judgment based on specific circumstances.

[0122] For processes not found in the mapping table, the system marks them as "UNKNOWN" and records the process name for later analysis. Through statistical analysis, the system can discover new common processes and update the mapping table.

[0123] S5.3: Extracting Process Behavior Features The system counts the number of operations and the set of files accessed by the same process within a preset time window to obtain process behavior characteristics. The system maintains a behavior statistics record for each active process. Operation Count Statistics: Set a time window (e.g., 10 seconds, 1 minute, 10 minutes) to count the total number of events triggered by the process within that time window. High-frequency operations (e.g., triggering dozens of events per second) may be compilers, build tools, or batch processing scripts, requiring batch processing strategies. Low-frequency operations (e.g., a few events per minute) may be editors or user-interactive operations, requiring timely responses.

[0124] File Set Statistics: Record all file paths operated on by the process, forming a file set. Analyze the characteristics of the file set, such as the number of files, file type distribution, and directory where the files are located. If a process operates on hundreds of .o files in a short period of time, it is likely that the compiler process is compiling the project. If a process repeatedly operates on the same file, it may be the editor's autosave function.

[0125] Operation type distribution statistics: This section analyzes the distribution of the number of various events (CREATE, MODIFY, DELETE, MOVE) triggered by the process. For example, editor processes typically generate more MODIFY events, compiler processes generate more CREATE events, and cleanup scripts generate more DELETE events. The operation type distribution helps identify process behavior patterns.

[0126] File access pattern recognition: Analyzing the order and patterns in which processes access files. For example, editors typically create swap files first, then modify source files, and finally delete swap files, forming a fixed access pattern. Compilers usually access source and header files in dependency order to generate corresponding object files. By recognizing these patterns, the system can predict the subsequent behavior of processes.

[0127] Process lifecycle tracking: Records the start and end times of processes (by checking if the process still exists) and calculates the process's runtime. Short-lived processes (e.g., a few seconds) may be rapidly executing scripts or commands, while long-lived processes (e.g., running continuously for hours) may be IDEs, editors, or background services. Process lifecycle information helps determine the completeness of operations; for example, the completion of a compilation process confirms that the compilation operation has been finished.

[0128] Process concurrency analysis: This counts the number of similar processes running concurrently. For example, if multiple gcc processes are running simultaneously, it indicates that parallel compilation is in progress, and the resulting events should be treated as a single compilation operation.

[0129] By extracting these process-dimensional features, the system can understand the process intent behind file operations, distinguish the operation modes of different software, and provide key contextual information for intelligent filtering decisions. Example

[0130] This embodiment details the construction process of the operation mode rule base.

[0131] Based on software operation behavior pattern information, operation pattern rules are constructed, including trigger conditions, matching priorities, and processing actions, resulting in an operation pattern rule library. This library includes: editor operation pattern rules based on file operation sequence information of editor software, containing event sequence trigger conditions for swap file creation, original file modification, and swap file deletion, with the processing action set to synchronize only the last modification of the original file; compiler operation pattern rules based on file operation sequence information of compiler software, containing intermediate file batch creation trigger conditions, with the processing action set to delayed synchronization; and version control operation pattern rules based on file operation sequence information of version control tools, containing lock file creation, lock file modification, and lock file renaming event sequence trigger conditions, with the processing action set to delayed synchronization. The processing action of the version control operation mode rule is to only synchronize the final state; based on the file operation sequence information of the office software, an office software operation mode rule containing temporary file prefix mode triggering conditions is constructed, and the processing action of the office software operation mode rule is set to filter temporary files; based on the file operation sequence information of application atomic writes, an atomic write operation mode rule containing event sequence triggering conditions of temporary file creation, data writing, and renaming overwrite is constructed, and the processing action of the atomic write operation mode rule is set to wait for the renaming to complete before synchronizing; the editor operation mode rule, the compiler operation mode rule, the version control operation mode rule, the office software operation mode rule, and the atomic write operation mode rule are sorted and stored according to matching priority to obtain the operation mode rule library.

[0132] S6.1: Constructing Editor Operation Mode Rules Based on the file operation sequence information of the editor software, editor operation mode rules are constructed. Taking Vim editor as an example, its typical file saving operation sequence is as follows: The user opens and edits the file example.txt in Vim; Vim creates a swap file named .example.txt.swp for crash recovery; When a user modifies the contents of a file, Vim periodically writes the changes to a swap file. When the user executes the save command (:w), Vim will write the changes to the original file example.txt. After saving successfully, Vim deletes the swap file .example.txt.swp; The corresponding file system event sequence is: Event1: CREATE .example.txt.swp; Event2: MODIFY .example.txt.swp (may occur multiple times); Event3: MODIFY example.txt; Event4: MODIFY .example.txt.swp; Event5: DELETE .example.txt.swp; The constructed Vim editor operation mode rules include the following elements: Rule name: "VimEditorSavePattern"; Triggering conditions (event sequence pattern): The sequence contains a CREATE event, and the filename matches the regular expression "^\..*\.sw[az]$" (swap file); The sequence contains a MODIFY event, and the filename is the original filename after removing the swap file prefix and suffix; The sequence contains DELETE events, with filenames identical to the swapped filenames of the CREATE events; All events span within a preset time window (e.g., 5 seconds); The process type that triggered the event is EDITOR, and the process name matches vim|vi|nvim; Matching priority: High priority (90), because Vim is a commonly used editor and this mode appears frequently; Processing actions: Perform FILTER (direct filtering) on ​​the CREATE and DELETE events of the exchange file; Execute FILTER on the MODIFY event of the swap file; Perform DELAY (delayed processing) on ​​the MODIFY event of the original file; When it is detected that the swap file has been deleted (operation completion indicator), IMMEDIATE is executed on the last MODIFY event of the original file (immediately triggering synchronization); Final result: Only the last modification to the original file is synchronized, ignoring all file swap operations; Confidence weight: 0.95 (This pattern recognition accuracy is very high); Similarly, build corresponding rules for other editors: Emacs editor rule "EmacsEditorSavePattern": Identify the creation and deletion patterns of #autosave# files and ~ backup files; Processing action: Filter out automatically saved and backup files, and only synchronize original files; VSCode editor rule "VSCodeEditorSavePattern": Identify and manipulate temporary files in the .vscode directory; Identify atomic write patterns (create temporary file → write → rename); Processing action: Wait for the atomic write to complete before synchronizing; S6.2: Constructing compiler operation mode rules Based on the file operation sequence information of the compiler software, compiler operation mode rules are constructed. Taking C / C++ compilation as an example, the typical event sequence of the compilation process is as follows: The user executes the make command to compile the project; The gcc / g++ compiler reads source files (.c / .cpp) and header files (.h / .hpp); The compiler generates an object file (.o) for each source file; The linker links object files into executable files or library files (.so / .a); The corresponding file system event sequence is: Event 1: CREATE main.o; Event2: CREATE utils.o; Event 3: CREATE helper.o; ... EventN: CREATE program.exe (or libprogram.so); The constructed C / C++ compiler operation mode rules include the following elements: Rule name: "CCompilerBuildPattern"; Triggering conditions: A batch of CREATE events occur within a short period of time (e.g., 10 seconds) (the number exceeds the threshold, e.g., 5 events); The created files have compilation artifacts with extensions such as .o, .obj, .so, .dll, .a, .lib, and .exe. The process type that triggered the event is COMPILER, and the process name matches gcc|g++|clang|cc|ld|make; Optional: The corresponding source files (.c / .cpp files) exist in the same directory; Matching priority: High priority (85); Processing actions: Execute the DELAY event for the CREATE event of all intermediate compilation files (.o, .obj, etc.); Set a delay time window (e.g., 15 seconds) and wait for the compilation process to complete. BATCH batch processing is executed after the compilation process ends or the delay time expires. For the MODIFY event of the source file, execute IMMEDIATE (immediately synchronize source file modifications); For compilation artifacts, whether to synchronize depends on the configuration (intermediate files are usually not synchronized, but the final executable file or library files may be synchronized). Confidence weight: 0.90; Similarly, build rules for other compilation environments: Java Compiler Build Pattern: Recognizes batch creation of .class files; Identify the generation of .jar files; Action taken: Delay synchronization and wait for compilation to complete; Python bytecode pattern: Identify the creation of the __pycache__ directory and .pyc files; Processing action: Direct filtering, bytecode files not synchronized; Frontend Build Pattern: Batch operations that identify the node_modules directory; Identify the generation of the dist and build directories; Processing actions: Filter dependency library directories and delay the synchronization of build artifacts; S6.3: Build version control operation mode rules Based on file operation sequence information from version control tools, version control operation pattern rules are constructed. Taking Git as an example, a typical operation sequence for updating an index file is as follows: Git requires updating the .git / index file to record file status; Git creates the lock file .git / index.lock; Git writes the new index content to the lock file; Git renames the lock file to .git / index and completes the update atomically; The corresponding file system event sequence is: Event1: CREATE .git / index.lock; Event 2: MODIFY .git / index.lock (may occur multiple times); Event3: MOVE_FROM .git / index.lock; Event4: MOVE_TO .git / index; The constructed Git operation mode rules include the following elements: Rule name: "GitAtomicUpdatePattern"; Triggering conditions (event sequence pattern): The sequence contains a CREATE event, the file path includes .git / , and the filename ends with .lock; The sequence contains MODIFY events and operates on the same .lock file; The sequence contains MOVE_FROM and MOVE_TO events; rename the .lock file to the target file. All events span within a preset time window (e.g., 2 seconds); The process type that triggered the event is VCS, and the process name is git; Matching priority: High priority (88); Processing actions: Execute FILTER on the CREATE and MODIFY events of the .lock file; Perform CONDITIONAL (conditional trigger) on the MOVE operation; When the MOVE_TO event (operation completion flag) is detected, IMMEDIATE is executed on the target file (e.g., .git / index); Final result: Only the final .git / index file is synchronized, ignoring all operations on .lock files; Confidence weight: 0.92; Similarly, build rules for other version control tools: SVN operation rules "SVNOperationPattern": Identify temporary files and lock files in the .svn directory; Processing action: Filter temporary files and only synchronize the final state; Git workspace update rule "GitWorkspaceUpdatePattern": Identify batch file changes caused by operations such as git checkout and git pull; Processing action: Batch processing, synchronized once the operation is complete; S6.4: Constructing Office Software Operation Mode Rules Based on file operation sequence information from office software, rules for office software operation patterns are constructed. Taking Microsoft Office as an example, the typical operation sequence for editing a Word document is as follows: The user opens the document.docx file; Word creates a temporary file ~$document.docx as a lock file; User-edited documents are automatically saved by Word periodically. When a user saves a document, Word updates document.docx. When the user closes the document, Word deletes the temporary file ~$document.docx. The corresponding file system event sequence is: Event1: CREATE ~$document.docx; Event 2: MODIFY document.docx (auto-saved, may be saved multiple times); Event 3: MODIFY document.docx (saved by the user); Event4: DELETE ~$document.docx; The constructed Office operating mode rules include the following elements: Rule name: "MSOfficeEditPattern"; Triggering conditions: Filenames begin with ~$ (Office temporary file prefix); Or the file has the .tmp extension and is located in the same directory as the Office document; The process type that triggered the event is OFFICE, and the process name matches winword|excel|powerpnt; Matching priority: High priority (87); Processing actions: Execute FILTER on all events of temporary files starting with ~$; Execute DELAY on the MODIFY event of the original document; When it is detected that a temporary file has been deleted (document close flag), IMMEDIATE is executed on the last MODIFY event of the original document; Final result: Filter out all temporary files and only synchronize the final saved state of the original document; Confidence weight: 0.93; Similarly, rules can be built for other office software: LibreOffice rule "LibreOfficeEditPattern": Identify lock files that begin with ".~lock."; Processing action: Filter locked files, only synchronize the original document; PDF reader rule "PDFReaderCachePattern": Identify temporary cache files such as .pdf and .tmp; Processing action: Direct filtering; S6.5: Constructing atomic write operation mode rules Based on the file operation sequence information of atomic writes by applications, atomic write operation pattern rules are constructed. Many applications use an atomic write pattern of "write temporary file → rename and overwrite" to ensure data consistency. A typical operation sequence is as follows: The application creates a temporary file temp_XXXXX.tmp; The application writes new data to a temporary file; The application renames the temporary file to the target file, overwriting the old file; The corresponding file system event sequence is: Event1: CREATE temp_a3f5b9.tmp; Event2: MODIFY temp_a3f5b9.tmp (may occur multiple times); Event3: MOVE_FROM temp_a3f5b9.tmp; Event4: MOVE_TO target_file.dat; The constructed atomic write operation mode rules include the following elements: Rule name: "AtomicWritePattern"; Triggering conditions (event sequence pattern): The sequence contains a CREATE event, and the filename contains temporary file identifiers such as temp and tmp, or contains a random string; The sequence contains MODIFY events and operates on the same temporary file; The sequence includes MOVE_FROM and MOVE_TO events, renaming the temporary file to the target file; All events span within a preset time window (e.g., 3 seconds); Temporary files and target files are in the same directory; Matching priority: Medium (75), because this pattern is quite common; Processing actions: Execute FILTER on the CREATE and MODIFY events of temporary files; Perform CONDITIONAL on the MOVE operation; When the MOVE_TO event (atomic write complete flag) is detected, IMMEDIATE is executed on the target file; Final result: Synchronize the target file after the atomic write is complete, ignoring temporary files; Confidence weight: 0.85; S6.6: Organization and Storage of the Rule Base The editor operation mode rules, compiler operation mode rules, version control operation mode rules, office software operation mode rules, and atomic write operation mode rules are sorted and stored according to matching priority. The rule base is stored in YAML format, and an example structure is as follows: rules: - name: "VimEditorSavePattern" priority: 90 type: "EDITOR" conditions: process_name_pattern: "vim|vi|nvim" event_sequence: - event_type: "CREATE" file_pattern: "^\\..*\\.sw[az]$" - event_type: "MODIFY" file_pattern: "^[^\\.].*" - event_type: "DELETE" file_pattern: "^\\..*\\.sw[az]$" time_window: 5000 # milliseconds actions: - target: "swap_file" action: "FILTER" - target: "original_file" action: "DELAY_THEN_IMMEDIATE" confidence: 0.95 - name: "CCompilerBuildPattern" priority: 85 type: "COMPILER" conditions: process_name_pattern: "gcc|g\\+\\+|clang|make" batch_create_threshold: 5 file_extension_pattern: "\\.o|\\.obj|\\.so|\\.a" time_window: 10000 actions: - target: "intermediate_files" action: "DELAY" - target: "source_files" action: "IMMEDIATE" confidence: 0.90 # ... Other rules The rule base supports the following features: Rule inheritance: General rules can be inherited and extended by specific rules. For example, the general "EditorPattern" rule can be inherited by "VimEditorPattern" and "EmacsEditorPattern".

[0133] Rule combination: Complex scenarios can be achieved by combining multiple simple rules using AND, OR, and NOT logical operators.

[0134] Rule Enable / Disable: Each rule can be enabled or disabled individually, facilitating debugging and customization.

[0135] User-defined rules: Users can add custom rules to override or supplement preset rules.

[0136] Rule version management: The rule base supports version control and can be rolled back to historical versions.

[0137] After the rule base is sorted by priority, it is traversed in order during pattern matching. Rules with higher priority are matched first. Once a match is successful and the confidence exceeds the threshold, you can choose to stop subsequent matching (fast mode) or continue matching all rules and select the best match (precise mode).

[0138] By building such a rich rule base for operation patterns, the system can accurately identify file operation behaviors of various common software, providing a solid knowledge foundation for intelligent filtering decisions. Example

[0139] This embodiment details the specific implementation process of pattern matching and confidence calculation.

[0140] Based on the multi-dimensional event feature vector and the operation pattern rule base, pattern matching is performed on the event sequence and the matching confidence is calculated to obtain the pattern matching result. This includes: receiving the multi-dimensional event feature vector as input, traversing the rules in the operation pattern rule base according to the matching priority; performing matching judgment on the triggering conditions of the current rule, including file name pattern matching, event sequence pattern matching, and process type matching; calculating the matching confidence of the current rule based on the number of matched features and the matching quality; selecting the rule with the highest matching confidence that exceeds a preset threshold as the best matching rule to obtain the pattern matching result.

[0141] S7.1: Receive input and initialize the matching process The system receives a multi-dimensional event feature vector as input. This feature vector includes the time-dimension, file-dimension, process-dimension, and path-dimension features extracted in the aforementioned embodiments. The feature vector is organized in a structured data format, with each dimension's features stored as key-value pairs for easy subsequent fast querying and matching. The system initializes the matching context, including creating a candidate matching rule list, initializing the confidence calculator, and setting the matching timeout. To improve matching efficiency, the system performs preliminary filtering based on the event's basic characteristics. For example, if the event's file extension is a plain text file and the process type is unknown, rules specifically targeting editor-exchanged files or compiler intermediate files can be skipped, thereby reducing unnecessary matching calculations.

[0142] The system traverses the rules in the operation mode rule base according to matching priority. The rule base is sorted by priority from highest to lowest upon loading, and rules with the same priority are sorted by confidence weight. The traversal process uses an iterator pattern and supports early termination of matching. In fast matching mode, once a matching rule with a confidence score exceeding a high threshold is found, the system can immediately return that rule as the matching result and stop traversing subsequent rules. In exact matching mode, the system traverses all rules, collects all possible matches, and finally selects the rule with the highest confidence score. Users can choose the appropriate matching mode based on performance and accuracy requirements.

[0143] S7.2: Filename Pattern Matching The system matches and judges the filename pattern triggering conditions of the current rule. The filename pattern defined in the rule can take various forms, including wildcard patterns, regular expression patterns, prefix and suffix exact matching patterns, etc. The system first extracts filename-related features such as filename, extension, and base name from the event feature vector, and then compares them with the pattern defined in the rule.

[0144] For wildcard patterns, the system supports matching the asterisk (*) and question mark (*) wildcards. An asterisk can match any sequence of characters of any length, while a question mark can match a single arbitrary character. For example, if the rule defines the filename pattern ".swp", the system will check if the file extension of the event is ".swp", and if so, the match is successful. For more complex patterns such as "..sw?", the system will check if the filename begins with a dot (.), and if the extension begins with "sw" followed by an arbitrary character. This can match various Vim swap files such as ".file.swp", ".file.swo", and ".file.swn".

[0145] For regular expression patterns, the system uses a regular expression engine for matching. Regular expressions defined in the rules can express more complex filename patterns. For example, "^\$.*\.docx$" can precisely match temporary files in Microsoft Word, requiring filenames to begin with "$" and end with ".docx". Regular expressions also support capturing groups, which can extract specific parts of filenames for subsequent processing, such as extracting the version number "1.2.3" from "file_v1.2.3.txt". The system sets a timeout limit when performing regular expression matching to prevent performance issues caused by complex regular expressions.

[0146] For exact prefix and suffix matching, the system provides an optimized, fast matching path. Many rules only need to check if a filename starts with a specific prefix or ends with a specific suffix, such as checking if it starts with "~$" or ends with ".tmp". This type of matching can be done through simple string comparison, without the need for complex pattern matching algorithms, and its execution efficiency is far higher than regular expression matching. The system automatically recognizes these simple patterns and prioritizes using the fast matching path.

[0147] The system also supports both case-sensitive and case-insensitive matching modes. On case-insensitive file systems such as Windows and macOS, filename matching defaults to case-insensitive mode, meaning "File.TXT" and "file.txt" are considered the same filename. On case-sensitive file systems such as Linux, filename matching defaults to case-sensitive mode. Rules can explicitly specify the matching mode, overriding the default behavior. When performing case-insensitive matching, the system converts both the filename and the pattern to lowercase before comparison.

[0148] S7.3: Event Sequence Pattern Matching The event sequence pattern triggering conditions of the current rule are matched and judged. The event sequence pattern describes a series of related events occurring in a specific order, such as the sequence "create swap file → modify original file → delete swap file" corresponding to the editor save operation, and the sequence "create temporary file → write data → rename to target file" corresponding to the atomic write operation. Event sequence pattern matching is the most complex and critical part of rule matching, which requires identifying event subsequences that conform to specific patterns in the event stream.

[0149] The system uses a finite state machine to implement event sequence pattern matching. For each event sequence pattern defined in the rules, the system constructs a finite state machine. Each state of the state machine corresponds to a position in the sequence, and state transitions correspond to the occurrence of an event. The state machine starts from the initial state. Whenever a new event is received, it determines whether the transition conditions of the current state are met based on the event type, file name, and other characteristics. If the conditions are met, the system transitions to the next state; otherwise, it maintains the current state or reverts to the previous state. When the state machine reaches the terminal state, it indicates that the complete event sequence pattern matching has been successful.

[0150] Taking the Vim editor's save operation as an example, the corresponding state machine contains four states. The initial state S0 waits for a swap file creation event. When a CREATE event is detected and the filename matches the pattern ".*.sw[az]", it transitions to state S1 and records the swap filename. State S1 waits for an original file modification event. When a MODIFY event is detected and the filename is the original filename with the swap file's prefix and suffix removed, it transitions to state S2. State S2 can accept multiple original file modification events to remain in the current state, or it can transition to the termination state S3 when a swap file deletion event is detected. Reaching state S3 indicates that the complete Vim save operation sequence has been successfully matched.

[0151] The system supports two modes: partial sequence matching and complete sequence matching. In partial sequence matching mode, a match can still be achieved as long as the event sequence contains the key events defined by the rules, even if some minor events are missing, but the confidence level will decrease accordingly. For example, the key events for a Vim save operation are original file modification and swap file deletion. If these two events are detected but the swap file creation event is missing, a partial match can still be achieved, but the confidence level will decrease from 0.95 to 0.80. In complete sequence matching mode, all events defined by the rules must be strictly matched for a successful match. This mode is more accurate but may miss some incomplete operation sequences.

[0152] The system also supports time window constraints in event sequences. Rules can define that the entire event sequence must be completed within a specific time window; for example, all events in a Vim save operation should be completed within 5 seconds, and atomic write operations should be completed within 3 seconds. During the matching process, the system checks the timestamps of the events. If the time span of events in the sequence exceeds the time window defined by the rule, the match fails. Time window constraints help distinguish truly relevant event sequences from irrelevant events that happen to be close in time.

[0153] For event sequences involving multiple files, the system needs to establish relationships between the files. For example, an atomic write operation involves two files: a temporary file and a target file. The system needs to identify the renaming relationship between these two files. The system establishes file relationships by analyzing the cookie values ​​of the MOVE_FROM and MOVE_TO events or the temporal proximity of the events. For compilation operations, the system needs to identify the correspondence between source files and compilation artifacts, such as "main.c" corresponding to "main.o". This association is established by matching the base names of the filenames.

[0154] S7.4: Process type matching The system matches and determines the process type triggering condition of the current rule. The rule defines the expected process type, such as EDITOR, COMPILER, VCS, OFFICE, etc., as well as optional process name patterns. The system extracts the process type and process name from the event feature vector and compares them with the conditions defined in the rule.

[0155] Process type matching is relatively simple; the system directly compares the process type of the event with the process type required by the rule. If the rule requires the process type to be EDITOR, while the event's process type is COMPILER, the process type match fails, and the rule does not apply to the current event. If the rule does not specify a process type requirement, the process type check is skipped, and the rule can match events of any process type.

[0156] Process name pattern matching uses a mechanism similar to filename pattern matching, supporting wildcards and regular expressions. For example, if a rule defines the process name pattern as "vim|vi|nvim", the system will check if the process name of the event is one of these three values. Regular expression patterns can express more flexible matching conditions; for example, "g(cc|++)|clang" can match multiple compiler processes such as gcc, g++, and clang. When performing process name matching, the system removes path prefixes and only compares the base name of the process; for example, " / usr / bin / gcc" and "gcc" are considered to be the same process name.

[0157] For certain rules, the system also checks the process's command-line arguments for a more precise match. For example, different subcommands executed by the git process produce different file operation patterns; "git commit" and "git pull," although both are git processes, have different operational natures. The system can identify the specific git operation by parsing the command-line arguments, thus applying more precise rules. Command-line argument matching uses string inclusion or regular expression matching, such as checking if the command line contains the keyword "commit".

[0158] The system also supports matching process hierarchy relationships. Some rules may require events to be triggered by child processes started by a specific parent process. For example, a compiler process started by an IDE may require different handling strategies than a compiler process started manually by the user. The system verifies process hierarchy relationships by checking the parent process ID and parent process name. This hierarchy matching provides richer contextual information and improves the accuracy of rule matching.

[0159] S7.5: Calculate the matching confidence score Based on the number of matched features and the quality of the match, the matching confidence of the current rule is calculated. The confidence score is a value between 0 and 1, representing how reliably the current event sequence matches the rule. The higher the confidence score, the more reliable the match, and the more likely the processing action defined by the rule should be executed.

[0160] The confidence score calculation considers multiple factors. First is the feature matching degree, which is the degree to which the event features match the rule requirements. If all features match perfectly, the feature matching degree is 1.0; if only some features match, the feature matching degree is calculated based on the proportion of matching features. For example, if a rule defines three conditions: filename pattern, process type, and event sequence, and the filename and process type match but the event sequence only partially matches, the feature matching degree might be 0.8. The system assigns different weights to different features, with key features receiving higher weights; for example, the weight of the event sequence pattern might be twice the weight of the filename pattern.

[0161] Secondly, there's sequence integrity, which refers to whether the event sequence completely matches the pattern defined by the rules. If a complete event sequence is detected, the sequence integrity is 1.0; if only a partial sequence is detected, the sequence integrity is calculated as the proportion of detected events to the total number of events. For example, if a Vim save operation defines five events, and only three critical events are detected, the sequence integrity is 0.6. The system distinguishes between critical and minor events; the absence of minor events has a smaller impact on sequence integrity, while the absence of critical events significantly reduces it.

[0162] Thirdly, there's the time window compliance, which refers to whether the time interval between events conforms to the rule requirements. If all relevant events occur within the time window defined by the rule, the time window compliance is 1.0; if the event time span exceeds the time window but is still within an acceptable range, the time window compliance will be appropriately reduced. For example, if the rule defines a time window of 5 seconds, and the actual event sequence is completed within 6 seconds, the time window compliance may decrease to 0.9; if it's completed within 10 seconds, it may decrease to 0.7. The system uses a Gaussian function or a piecewise linear function to calculate the time window compliance, ensuring that the compliance decreases smoothly with time deviation.

[0163] Fourth is historical accuracy, which is the accuracy rate of the rule in historical matches. The system counts the number of historical matches, successful matches, and failed matches for each rule and calculates the accuracy rate. If a rule has a high historical accuracy rate, it indicates that the rule is well-defined and the matching results are reliable, and the system will increase the confidence weight of that rule. If a rule frequently produces false positives and has a low historical accuracy rate, the system will decrease the confidence weight of that rule. Historical accuracy is collected through user feedback and automatic verification mechanisms, such as user manual confirmation or cancellation of synchronization operations, which allows the system to determine whether the rule matching is correct.

[0164] The final matching confidence score is calculated using a weighted average, with the formula: Confidence Score = Rule Base Weight × (α × Feature Matching Degree + β × Sequence Integrity + γ × Time Window Compliance) × Historical Accuracy Adjustment Factor. Here, α, β, and γ are configurable weight coefficients, typically set to α=0.3, β=0.5, and γ=0.2, indicating that sequence integrity is the most important factor, followed by feature matching degree, and time window compliance has the least impact. The rule base weight is obtained from the rule definition and reflects the rule designer's assessment of the rule's reliability. The historical accuracy adjustment factor is dynamically adjusted based on historical statistics, with an initial value of 1.0. If the historical accuracy is higher than 95%, it increases to 1.1; if it is lower than 80%, it decreases to 0.9.

[0165] S7.6: Select the best matching rule The rule with the highest confidence level exceeding a preset threshold is selected as the best matching rule to obtain the pattern matching result. The system maintains a list of candidate matching rules. During the traversal of the rule base, all rules with a confidence level exceeding the minimum threshold are added to the candidate list. The minimum threshold is usually set to 0.6; matches below this threshold are considered unreliable and are not considered.

[0166] In fast matching mode, the system sets a high confidence threshold, typically 0.9. Once a rule with a confidence level exceeding this threshold is found, the system immediately returns that rule as the best match and stops iterating through subsequent rules. This mode is suitable for scenarios with high performance requirements, significantly reducing matching computation time. Because the rule base is already sorted by priority, higher-priority rules are checked first, so fast matching mode can quickly find the correct matching rule in most cases.

[0167] In exact matching mode, the system iterates through all rules, collecting all candidate rules with a confidence level exceeding the minimum threshold. After iteration, the system selects the rule with the highest confidence level from the candidate list as the best match. If multiple rules have the same highest confidence level, the system selects the rule with higher priority; if the priorities are also the same, the system selects the rule that appears earlier in the rule definition. Exact matching mode is suitable for scenarios with high accuracy requirements. Although the computation time is longer, it ensures that the most suitable rule is selected.

[0168] If no rule's confidence exceeds the minimum threshold, the system returns an empty match, indicating that the current event sequence does not match any known operation pattern. In this case, the system adopts a default processing strategy, typically marking the event as requiring immediate synchronization to ensure no real user actions are missed. Simultaneously, the system records these unmatched event patterns as candidates for rule base expansion, for use in subsequent analysis and rule generation.

[0169] The pattern matching results contain complete information about the best matching rule, including the rule name, rule type, matching confidence, the sequence of matched events, and the processing actions defined by the rule. This information is passed to the subsequent filtering decision module to determine the final processing method for the events. The system also records detailed logs of the matching process, including which rules were checked, the confidence calculation results for each rule, and why a rule was selected or rejected. These logs are invaluable for debugging the rule base and optimizing the matching algorithm.

[0170] Through this systematic pattern matching and confidence calculation mechanism, the system can accurately identify the file operation patterns of various software, providing a reliable basis for intelligent filtering decisions while maintaining good performance and scalability. Example

[0171] This embodiment details the specific implementation process of filtering decisions and event handling.

[0172] Based on the pattern matching results, the filtering strategy type is determined and corresponding filtering processing is performed on the events, outputting the event filtering decision result. This includes: determining the event filtering strategy type based on the processing actions of the matching rules in the pattern matching results. The filtering strategy type includes direct filtering, delayed processing, conditional triggering, immediate triggering, and batch triggering. For events with the filtering strategy type of delayed processing or conditional triggering, the events are added to the event waiting queue, and the event information, the time of adding to the queue, and the waiting timeout are recorded to obtain the event queue to be decided. The events in the event queue to be decided are subjected to correlation analysis to identify events generated by the same process, multiple operation events of the same file, and related operation events under the same directory, and causal dependencies between events are constructed to obtain an event correlation graph. Based on the event correlation graph, the key start and end events of the event sequence are identified, and it is determined whether the operation sequence has been completed to obtain the operation integrity judgment result. Based on the filtering strategy type, the event correlation graph, and the operation integrity judgment result, events of the direct filtering type are ignored, events of the immediate trigger type are synchronously triggered, events of the delayed processing type whose operations have been completed are synchronously triggered, and events whose operations have not been completed continue to wait to obtain the event filtering decision result.

[0173] S8.1: Determine the filtering strategy type Based on the processing actions of matching rules in the pattern matching results, the system determines the filtering strategy type for events. Each rule specifies one or more processing actions during its definition, which describe how an event should be processed when it matches the rule. The system maps the processing actions defined in the rules to five standard filtering strategy types: direct filtering, delayed processing, conditional triggering, immediate triggering, and batch triggering.

[0174] Direct filtering is suitable for explicit temporary and system files whose operation events are meaningless to the user and should be completely ignored. Typical direct filtering scenarios include editor swap files, such as Vim's .swp files and Emacs' #autosave# files; temporary files in office software, such as Word temporary files starting with ~$; lock files in version control tools, such as .git / index.lock files; and various temporary files ending with extensions like .tmp, .temp, and .bak. When an event matches this type of rule, the system immediately sets the filtering strategy to direct filtering. The event will not trigger any subsequent processing, will not enter the waiting queue, and will not generate any synchronization operations. Direct filtering is the most thorough filtering method, which can significantly reduce the number of events the system needs to process and improve overall performance.

[0175] Deferred processing strategies are suitable for situations where observing subsequent events is necessary to make the correct decision. Many software file operations are completed in multiple steps. For example, an atomic write operation first creates a temporary file, writes the data, and finally renames it to the target file. The true intent of the operation can only be confirmed after the renaming is complete. Compilation operations are also typical deferred processing scenarios. During compilation, the compiler creates a large number of intermediate files, but only after compilation is complete does it become clear which final outputs need to be retained. For these types of events, the system sets the filtering strategy to deferred processing. The event is added to a waiting queue, and the system continuously observes subsequent events until a marker event indicating the operation's completion is detected or the wait times out, before making a final processing decision.

[0176] Conditional triggering strategies are a special form of delayed processing that determines whether to trigger synchronization based on the specific circumstances of subsequent events. For example, in an atomic write operation on a temporary file, if a rename event is subsequently detected, it means the temporary file has become the target file, and synchronization should be triggered; if a delete event is subsequently detected, it means the operation has been cancelled, and synchronization should not be triggered. Conditional triggering strategies require establishing dependencies between events and making decisions by analyzing the completeness of the event sequence. The system sets multiple possible trigger conditions for conditional events, each condition corresponding to a different subsequent event pattern and corresponding processing action.

[0177] The immediate trigger strategy applies to clearly defined and valid operations that should trigger file synchronization immediately. Typical scenarios include users directly editing and saving source code files, copying or moving important documents, and creating new project files. When an event matches this type of rule, the system sets the filtering strategy to immediate trigger, and the event immediately generates a synchronization task, notifying the file synchronization system to perform the actual synchronization operation. The immediate trigger strategy ensures the real-time nature of user operations, guaranteeing that important file modifications can be synchronized to the target location in a timely manner.

[0178] Batch triggering strategies are suitable for batch operation scenarios. They aggregate multiple related events and trigger synchronization in batches. Compilation is a typical batch triggering scenario, during which dozens or even hundreds of source files may be modified. If synchronization is triggered immediately for each file modification, a large number of synchronization tasks will be generated, impacting system performance. The batch triggering strategy waits for the entire compilation operation to complete, and then triggers synchronization for all modified source files as a batch, ensuring the integrity of synchronization while avoiding frequent synchronization operations. The system sets an aggregation window for batch triggering, collecting relevant events within the window period and processing them uniformly when the window ends.

[0179] S8.2: Construct a queue of events to be decided For events with filtering strategies of delayed processing or conditional triggering, the system adds the event to the event waiting queue. The waiting queue is a time-ordered data structure that stores events awaiting decision in the order they were added to the queue. Each queue record contains complete event information, including raw data such as event type, timestamp, file path, and process information, as well as decision-related data such as matching rule information, filtering strategy type, and confidence level.

[0180] The system records the time each event is added to the queue; this time is used to calculate the event's waiting time in the queue. Simultaneously, the system sets a timeout for each event based on the matching rules and the specific circumstances of the event. The timeout setting needs to balance the expected completion time of the operation with the real-time requirements of the system response. For editor save operations, the timeout is typically set to a shorter value, such as 5 seconds, because editor save operations usually complete within a few seconds, and excessive waiting time would negatively impact user experience. For compile operations, the timeout can be set to a longer value, such as 30 seconds or even 1 minute, because compiling large projects can take longer. For version control operations, the timeout is typically set to around 10 seconds, which is sufficient to cover the completion time of most Git operations.

[0181] The system periodically scans the waiting queue, checking the waiting time for each event. If the waiting time exceeds the set timeout, the system will force a decision to prevent the event from waiting indefinitely. The specific behavior of the timeout decision depends on the rule definition. For delayed processing strategies, synchronization is usually triggered after a timeout to ensure that no user operation is missed; for conditional triggering strategies, the best guess based on observed events may be made after a timeout, or a conservative strategy may be adopted to trigger synchronization. The timeout mechanism is an important guarantee of system robustness, preventing abnormal situations from causing event processing to stall.

[0182] The implementation of a waiting queue needs to consider performance and concurrency safety. The system uses efficient data structures such as priority queues or skip lists to organize the waiting queue, supporting fast insertion, query, and deletion operations. The queue supports multi-threaded concurrent access, using fine-grained locks or lock-free data structures to reduce lock contention and improve concurrency performance. The system also implements queue capacity limits and backpressure mechanisms. When the length of the waiting queue exceeds a preset threshold, the system will take measures such as speeding up processing, increasing the priority of timeout decisions, or even pausing the reception of new events to prevent the queue from growing indefinitely and exhausting memory.

[0183] S8.3: Constructing an event relationship graph The system performs correlation analysis on events in the decision event queue to identify events generated by the same process, multiple operation events on the same file, and related operation events in the same directory. It then constructs causal dependencies between these events, resulting in an event correlation graph. The event correlation graph is a directed graph structure where nodes represent events and edges represent relationships or dependencies between them. By constructing this graph, the system can understand the connections between events from a global perspective and identify complex operation patterns.

[0184] Identifying events generated by the same process is the most basic association analysis. The system traverses all events in the waiting queue, groups events by process ID, and considers events belonging to the same process as related. A sequence of events generated by the same process often corresponds to a complete high-level operation; for example, a series of events in an editor process corresponds to a file editing and saving operation, and a series of events in a compiler process corresponds to a compilation operation. The system establishes associations for events within the same process; in the event association graph, these events are connected by "same process" edges. Same-process association helps identify the boundaries of operations and determine whether an operation has been completed.

[0185] Identifying multiple operation events on the same file allows for tracking file state changes. The system groups events based on file paths and arranges events for the same file chronologically, forming an operation timeline for that file. For example, a file may undergo operations such as creation, multiple modifications, renaming, and deletion; these operation events are connected in the association graph via "same file" edges. By analyzing the file's operation timeline, the system can identify the file's lifecycle and distinguish between temporary and persistent files. Temporary files typically undergo creation and deletion within a short period, with possibly a few modifications in between; persistent files exist for a long time and may involve numerous modification operations. Associating files with the same file also helps merge redundant events; for example, multiple consecutive modifications to the same file can be merged into a single modification.

[0186] Identifying related operation events within the same directory can reveal batch operation patterns. The system groups events based on the directory where the files are located, analyzing directory-level operation patterns. For example, compilation operations typically create a large number of .o files in the same directory, version control operations generate numerous temporary and index files in the .git directory, and front-end build operations install a large number of dependency packages in the node_modules directory. The system statistically analyzes the number and type distribution of events for each directory within a time window. If a directory generates a large number of similar events within a short period, it is likely a batch operation. Events within the same directory are connected in the association graph via "same directory" edges, forming directory-level event clusters.

[0187] Constructing causal dependencies between events is the core of association analysis. The system infers causal relationships between events based on their type, time sequence, and file relationships. For example, the creation event of a temporary file is a prerequisite for a subsequent modification event, the modification event is a prerequisite for a renaming event, and the renaming event leads to the update of the target file. This causal chain is represented in the association graph by "dependency" edges, with the direction of the edge indicating the dependency relationship, pointing from the prerequisite event to the dependent event. The system uses heuristic rules to identify causal relationships. For example, if events A and B operate on related files, and event B occurs shortly after event A, then it is inferred that event B may depend on event A. For move operations, there is a clear causal relationship between the MOVE_FROM and MOVE_TO events, which the system associates using cookie values ​​or time proximity.

[0188] The construction of the event association graph is an incremental process. When a new event is added to the waiting queue, the system immediately analyzes the association relationship between the event and existing events in the queue and updates the association graph. When an event is removed from the queue, the system also updates the association graph, deleting related nodes and edges. Maintaining the association graph requires efficient graph data structures and algorithms. The system uses adjacency lists or adjacency matrices to store the graph structure, supporting fast addition, deletion, and query operations for nodes and edges. For large-scale event streams, the association graph may contain thousands of nodes and tens of thousands of edges. The system needs to optimize the storage and query performance of the graph to avoid it becoming a performance bottleneck.

[0189] S8.4: Determine the integrity of the operation Based on the event association graph, the system identifies the key start and end events of an event sequence to determine whether the operation sequence has been completed, thus obtaining an operation integrity judgment result. Operation integrity judgment is crucial in determining when to trigger synchronization; the system should only trigger synchronization after a complete operation sequence has been completed to avoid inconsistent states caused by synchronization midway through the operation.

[0190] A signature start event marks the beginning of an operation sequence. For an editor save operation, the signature start event is typically the creation of a swap file; for an atomic write operation, it's the creation of a temporary file; for a compile operation, it might be the reading of the first source file or the creation of the first object file. The system identifies the start event in an event sequence based on the definition of matching rules. In the association graph, the start event is usually a node with an in-degree of zero or a very small in-degree, indicating that it depends on no other events or only a few preconditions.

[0191] A marker end event signifies the completion of an operation sequence. For an editor save operation, the marker end event is the deletion of the swap file, indicating that the editor has successfully saved the file and cleaned up temporary files. For an atomic write operation, the marker end event is the renaming of the temporary file to the target file, indicating that the data has been safely written to the target location. For a compilation operation, the marker end event may be the generation of the final executable file or the termination of the compilation process. The system identifies end events in the event sequence according to the definition of matching rules. In the association graph, end events are typically nodes with zero or very small out-degrees, indicating that no other events depend on them or that only a few subsequent cleanup operations occur.

[0192] Determining whether an operation sequence has been completed requires considering several factors. First, the system checks if a significant termination event has been observed. If a termination event has been observed, and all intermediate events between the termination and start events have occurred, the operation sequence is considered complete. Second, the system checks the time span of the event sequence. If the time from the start event to the current moment exceeds the expected operation duration, the system may consider the operation complete or abnormally terminated even without a clear termination event observed. Third, the system checks the process status. If the process that triggered the event sequence has terminated, it usually indicates that the operation has been completed, even if some expected events have not occurred.

[0193] For certain complex sequences of operations, integrity checks may require more sophisticated logic. For example, compilation operations may involve the parallel execution of multiple compiler processes; the system must wait for all compiler processes to finish before considering compilation complete. Version control operations may involve the sequential execution of multiple sub-operations, such as staging files, updating indexes, and creating commit objects; the system needs to identify the completion of the entire operation chain. The system uses state machines or rule engines to implement complex integrity check logic. The state transitions of the state machine reflect the progression of the operation sequence; when the state machine reaches a terminal state, it indicates that the operation is complete.

[0194] The result of the operation integrity judgment is a Boolean value indicating whether the operation has been completed, and a confidence value indicating the reliability of the judgment. If a clear termination event is observed and the event sequence is complete, the confidence level is 1.0; if the inference is only based on timeout or process termination, the confidence level may be lower, such as 0.7. The system will consider the confidence level of the integrity judgment in subsequent decisions. A high-confidence judgment will immediately trigger the corresponding processing action, while a low-confidence judgment may require additional verification or adopt a conservative strategy.

[0195] S8.5: Perform filtering decisions Based on the filtering strategy type, event relationship graph, and operation integrity judgment results, the system performs corresponding processing for different types of events, obtaining event filtering decision results. The decision-making process comprehensively considers multiple aspects of information, such as the nature of the event, the relationship between events, and the integrity of the operation, to ensure that correct filtering and synchronization decisions are made.

[0196] For events that are directly filtered, the system ignores them. These events are marked as processed but do not trigger any synchronization operations; they will not appear in the final synchronization task list. The system records statistical information about these filtered events, such as the number of filtered events, file type distribution, and triggering process, for subsequent analysis and rule optimization. Directly filtered events are immediately removed from the waiting queue, freeing up system resources.

[0197] For events that trigger immediately, the system performs synchronous triggering. The system generates a synchronization task, containing information such as the file path to be synchronized, the synchronization type, and priority, and submits the task to the file synchronization system. The type of synchronization task is determined by the event type: the CREATE event corresponds to new file synchronization, the MODIFY event to file content update synchronization, the DELETE event to file deletion synchronization, and the MOVE event to file movement or renaming synchronization. The system sets priorities for synchronization tasks; events generated by user interactive operations have higher priority, while events generated by background tasks have lower priority. Events that trigger immediately are removed from the waiting queue after the synchronization task is generated.

[0198] For events with delayed processing, the system determines the handling method based on the operation integrity assessment. If the operation is complete, the system executes synchronization trigger processing, generating a corresponding synchronization task. A synchronization task may contain multiple files; for example, after an atomic write operation, the renamed target file needs to be synchronized, or after an editor save operation, the modified original file needs to be synchronized. The system extracts a list of files to be synchronized from the event graph, removes temporary and intermediate files, and retains only the final valid file. If the operation is not complete, the event continues to wait in the waiting queue, and the system continuously monitors subsequent events until it detects that the operation is complete or the wait times out.

[0199] For condition-triggered events, the system decides whether to trigger synchronization based on the specific circumstances of subsequent events. The system checks the event hierarchy graph for each subsequent event and determines the appropriate action based on its type and content. For example, in an atomic write operation on a temporary file, if the subsequent event is a rename event, the system triggers synchronization of the target file; if the subsequent event is a delete event, the system does not trigger any synchronization. The decision logic for condition-triggered events is specified in the rule definition, and the system executes the corresponding condition judgments and action selections according to the rules.

[0200] For batch-triggered events, the system waits for the aggregation window to close before processing all related events within the window as a single batch. The system identifies events belonging to the same batch from the event association graph; these are typically a series of events generated by the same process within a short period, or a large number of similar events in the same directory. The system extracts all files involved in the batch, removes duplicates and temporary files, and generates a batch synchronization task. This batch synchronization task involves synchronizing multiple files. The file synchronization system can optimize batch synchronization execution, for example, by using batch transfer protocols or synchronizing multiple files in parallel, thereby improving synchronization efficiency.

[0201] The event filtering decision result is a structured data object containing the decision type, a list of files involved, synchronization task information, and decision confidence level. Decision types include FILTER, SYNC_IMMEDIATE, and SYNC_BATCH, indicating the final handling method of the event. The file list contains the full paths and synchronization types of the files to be synchronized. Synchronization task information includes metadata such as task ID, priority, and creation time. Decision confidence level indicates the system's confidence in the correctness of the decision; high-confidence decisions can be executed automatically, while low-confidence decisions may require user confirmation.

[0202] The system outputs the filtering decision results to the file synchronization system and the user interface. The file synchronization system executes the actual file synchronization operation based on the decision results, and the user interface displays the synchronization activity and statistical information to the user. The system also records detailed logs of the decision results, including input information, the decision process, and the decision outcome, for auditing, debugging, and performance analysis. Through this systematic filtering decision mechanism, the system can accurately distinguish between valid and invalid operations, significantly reducing unnecessary synchronization and improving the overall efficiency of the file synchronization system. Example

[0203] This embodiment details the specific implementation process of adaptive rule base updates.

[0204] Based on the event filtering decision results and user feedback information, the operation mode rule base is adaptively updated, including: collecting execution feedback on the event filtering decision results, including the success rate of synchronization tasks, user-manually corrected operation records, and feature information of misjudged events; based on the execution feedback, calculating the accuracy, recall, and false positive rate of each rule, and updating the historical statistical data of the rules; identifying frequently occurring event patterns that are not matched by existing rules, extracting the common features of the event patterns, and generating candidate rules; verifying the candidate rules, calculating the performance indicators of the candidate rules on historical event data, and adding the candidate rules to the operation mode rule base when the performance indicators exceed a preset threshold; adjusting or disabling rules with an accuracy rate lower than the preset threshold, and reducing the priority or modifying the matching conditions of rules with a high false positive rate.

[0205] S9.1: Collect execution feedback The system continuously collects execution feedback on the results of event filtering decisions. This feedback is a crucial data source for evaluating rule performance and optimizing the rule base. The execution feedback includes three main aspects: the success rate of synchronization tasks, user-manually corrected operation records, and characteristic information of misjudged events.

[0206] The success rate of synchronization tasks reflects the correctness of filtering decisions. After the system generates a synchronization task, the file synchronization system executes the actual synchronization operation and returns the result. If synchronization completes successfully, it indicates that the filtering decision was correct and the synchronized file is indeed the valid file the user needs. If synchronization fails, it may be due to reasons such as file deletion, file permission issues, or network failure. The system needs to analyze the reasons for the failure to determine if it is related to the filtering decision. For example, if the system decides to synchronize a file but finds that the file no longer exists during synchronization, it may indicate that the file is a temporary file, and the filtering decision incorrectly classified it as a valid file. The system records the execution status of each synchronization task, including success, failure, and partial success, and calculates the success rate of synchronization tasks triggered by each rule. Rules with high success rates indicate that their filtering decisions are accurate and reliable, while rules with low success rates may have problems and require further analysis and adjustment.

[0207] User-manually corrected operation logs provide the most direct feedback. The system offers users an interface to view synchronization activities, manually confirm or cancel synchronization operations, and mark files that were incorrectly filtered. When a user cancels an automatically triggered synchronization task, it indicates that the system incorrectly classified an invalid operation as a valid one—a false positive. When a user manually adds a system-filtered file to the synchronization list, it indicates that the system incorrectly classified a valid operation as invalid—a false negative. The system records each user's manual correction operation, including the correction time, the file involved, the original filtering decision, and the rule that triggered that decision. These correction records are marked as high-confidence feedback data because they directly reflect the user's true intent and have high weight in rule optimization.

[0208] The characteristic information of misjudged events helps the system understand why rules fail. When a misjudgment is detected, the system analyzes the characteristics of the relevant event in depth, including filename patterns, event sequences, process information, and time characteristics. The system compares the misjudged event with the correctly judged event to identify the key characteristic differences that led to the misjudgment. For example, a rule might filter out all .tmp files, but if a user manually syncs a .tmp file, the system will analyze other characteristics of that file and find that it was created directly by the user's application, rather than being a temporary file automatically generated by the system or editor. This characteristic difference can be used to improve the rule, add more precise matching conditions, and prevent similar misjudgments from happening again.

[0209] The system also collects information on rule-unmatched events. For events that do not match any rules, the system records their complete characteristics and the final processing method. If these unmatched events eventually trigger synchronization, it indicates they are valid operations, and new rules may need to be created to identify similar operation patterns. If these unmatched events are marked by users as needing filtering, it indicates the existence of new temporary file patterns, and corresponding filtering rules also need to be created. The accumulation of unmatched events can reveal coverage blind spots in the rule base and guide the generation of new rules.

[0210] The collection of feedback is an ongoing process, with the system continuously accumulating feedback data during operation. To ensure the quality of the feedback data, the system performs noise reduction processing, filtering out obvious anomalies. For example, if a user frequently corrects the same type of decision within a short period, it may indicate that the user is testing the system or making a mistake; such feedback has low credibility. The system uses statistical methods and machine learning techniques to identify abnormal feedback, reducing their weight or ignoring them completely when updating rules.

[0211] S9.2: Update rule statistics Based on the collected execution feedback, the system calculates the precision, recall, and false positive rate for each rule and updates the historical statistical data for the rules. These performance indicators comprehensively reflect the effectiveness of the rules and serve as an important basis for rule optimization.

[0212] Accuracy measures the percentage of correct decisions triggered by a rule. The formula for accuracy is: Accuracy = Number of Correct Decisions / Total Number of Decisions. Correct decisions fall into two categories: those deemed valid by the rule and confirmed by the user, and those deemed invalid by the rule and confirmed by the user. The total number of decisions is the total number of decisions triggered by the rule. High accuracy indicates that the rule's judgment is reliable and produces few errors. The system maintains an accuracy counter for each rule, updating the counter based on subsequent feedback each time a rule triggers a decision. Accuracy calculation uses a sliding window mechanism, only counting decisions within a recent period, such as the last 1000 decisions or the last month. This reflects the rule's actual performance in the current environment and avoids interference from historical data.

[0213] Recall measures how many operations a rule can identify that should be identified. The formula for recall is: Recall = Number of operations correctly identified by the rule / Total number of operations that should be identified. For filtering rules, the operations that should be identified are all temporary file operations; recall reflects how many temporary files the rule can filter out. For triggering rules, the operations that should be identified are all valid user operations; recall reflects how many valid operations the rule can capture. Calculating recall requires knowing the total number of operations that should be identified, which is difficult to obtain directly. The system calculates it through sampling and estimation. The system periodically samples a batch of events, manually labels them, or uses user feedback to determine which operations should be identified by the rule. Then, it calculates the recall of the rule on this batch of samples and generalizes it to all events. A low recall indicates insufficient rule coverage, missing many operations that should be processed, requiring relaxed matching conditions or the creation of supplementary rules.

[0214] The false positive rate measures the proportion of incorrect decisions made by a rule. The formula for calculating the false positive rate is: False Positive Rate = Number of Incorrect Decisions / Total Number of Decisions. Incorrect decisions include false positives and false negatives. A false positive is when an invalid operation is mistakenly identified as a valid operation, and a false negative is when a valid operation is mistakenly identified as invalid. The system counts the number of these two types of errors separately because their impacts differ. False positives lead to unnecessary synchronization, wasting bandwidth and storage resources, but do not result in the loss of user data. False negatives result in valid files not being synchronized, potentially causing user data loss, with a more severe impact. When calculating the false positive rate, the system can assign a higher weight to false negatives to reflect their greater harm. A high false positive rate indicates that the rule's judgment is unreliable and needs to be adjusted or disabled.

[0215] The system also calculates rule coverage, which is the proportion of events matched by a rule out of the total number of events. Coverage reflects the frequency and importance of rule usage. Rules with high coverage handle a large number of events, significantly impacting system performance, and their accuracy and efficiency require special attention. Rules with low coverage handle only a small number of special cases; even if their accuracy is low, their impact on overall performance is limited. When optimizing rules, the system prioritizes optimizing rules with high coverage because improvements to them yield greater benefits.

[0216] These performance metrics are recorded in the rule's metadata, forming historical statistics for the rule. Each rule has a statistical data structure containing the current values ​​and historical trends of metrics such as accuracy, recall, false positive rate, and coverage. The system updates these statistics regularly, typically hourly or daily, to ensure that the statistics reflect the rule's latest performance. The statistics also include detailed information such as the rule's creation time, last modification time, number of triggers, number of successes, and number of failures, providing comprehensive data support for rule management.

[0217] S9.3: Generating Candidate Rules The system identifies frequently occurring event patterns that are not matched by existing rules, extracts common features from these patterns, and generates candidate rules. The generation of candidate rules is a crucial mechanism for the automatic expansion of the rule base, enabling the system to adapt to new software and operating modes without manual intervention.

[0218] The first step in identifying unmatched event patterns is to collect these unmatched events. The system maintains an unmatched event database, recording all events that do not match any rules. Unmatched events are categorized and aggregated based on features such as filename patterns, process types, and event sequences. The system uses clustering algorithms to group similar unmatched events together, with each cluster representing a potential new operational pattern. Clustering algorithms can be based on eigenvector distance (K-means), density (DBSCAN), or hierarchical clustering. The goal of clustering is to group events with similar characteristics, such that events within the same group likely correspond to the same operational pattern, while events in different groups correspond to different operational patterns.

[0219] For each event cluster, the system analyzes its frequency and importance. High-frequency clusters indicate that the corresponding operation pattern occurs frequently and warrants rule creation. Importance is determined through user feedback; if users frequently manually correct events within a cluster, the operation pattern is important to them and should be prioritized for rule creation. The system calculates a priority score for each cluster, taking into account factors such as frequency, importance, and number of events; higher-priority clusters are processed first.

[0220] Extracting common features of event patterns is the core step in candidate rule generation. The system analyzes the features of all events in the clusters and identifies their commonalities. For filename features, the system extracts common prefixes, suffixes, extensions, naming patterns, etc. For example, if files in the cluster all start with "build_" and end with ".log", the system will extract the filename pattern "build_*.log". For event sequence features, the system identifies the temporal order and type sequence of events in the clusters. For example, if events in the cluster are all in the sequence "CREATE → MODIFY → DELETE", the system will extract this sequence pattern. For process features, the system identifies the common type or name of the processes that triggered the events. For example, if events in the cluster are all triggered by a process named "webpack", the system will extract the process name "webpack".

[0221] The system uses pattern mining algorithms to automatically extract common features. Sequence pattern mining algorithms, such as PrefixSpan, can mine frequent subsequences from event sequences, which can serve as candidates for event sequence patterns. Association rule mining algorithms, such as Apriori, can discover associations between features, such as the association pattern "files with the .js extension and the process name is node". Decision tree algorithms can learn classification rules from labeled data, such as the rule "if a filename starts with ~ and is deleted within 1 second, it is a temporary file". These machine learning algorithms help the system automatically discover complex patterns without manual analysis.

[0222] Based on the extracted common features, the system generates candidate rules. The structure of candidate rules is the same as existing rules, consisting of two parts: matching conditions and processing actions. Matching conditions are composed of extracted features, such as filename patterns, event sequence patterns, and process types. Processing actions are inferred based on the nature of the events. If most events in a cluster are marked by users as needing filtering, the processing action is set to direct filtering; if most are marked as needing synchronization, the processing action is set to immediate triggering. The system also sets initial priority and confidence for candidate rules, typically at low values, because the candidate rules have not yet been fully validated.

[0223] The candidate rule generation process includes two steps: rule generalization and rule specialization. Rule generalization expands overly specific rules into more general ones; for example, generalizing "file1.tmp" to ".tmp" and "vim" to "vim|vi|nvim". Generalization improves rule coverage, enabling rules to match more similar events. Rule specialization refines overly broad rules into more precise ones; for example, specializing ".tmp" to "build_*.tmp" and "all CREATE events" to "CREATE and process is gcc". Specialization improves rule accuracy and reduces false positives. When generating candidate rules, the system generates both generalized and specialized versions simultaneously, selecting the best-performing version during subsequent verification.

[0224] S9.4: Validate candidate rules The generated candidate rules are validated, and their performance metrics on historical event data are calculated. When the performance metrics exceed a preset threshold, the candidate rule is added to the operation mode rule base. Rule validation is a crucial step in ensuring the quality of the rule base, preventing low-quality rules from polluting the rule base and affecting system performance.

[0225] The system uses historical event data as a validation dataset. This data includes all events processed by the system within a past period, along with their true labels—indicating whether an event should be filtered or synchronized. These labels come from user feedback, manual annotation, or the system's final processing results. The system divides the historical event data into training and test sets. The training set is used to generate candidate rules, and the test set is used to validate the performance of these rules. The typical split is 70% training and 30% test, or cross-validation can be used, dividing the data into multiple folds that alternately serve as the test set.

[0226] The system applies candidate rules to the test set to simulate the actual operation of the rules. For each event in the test set, the system checks whether a candidate rule matches the event; if a match is found, a decision is generated according to the processing action defined in the rule. The system compares the decisions of the candidate rules with the true labels of the events, and counts metrics such as the number of correct decisions, the number of incorrect decisions, the number of false positives, and the number of false negatives. Based on these statistics, the system calculates performance metrics for the candidate rules, including precision, recall, false positive rate, and F1 score.

[0227] The calculation methods for precision, recall, and false positive rate are the same as those for the aforementioned rule statistics. The F1 score is the harmonic mean of precision and recall, calculated as: F1 = 2 × (precision × recall) / (precision + recall). The F1 score comprehensively considers precision and recall and is a commonly used indicator for evaluating the overall performance of a rule. A high F1 score indicates that the rule is both accurate and comprehensive, representing a high-quality rule. The system also calculates the specificity of candidate rules (the rule's ability to correctly reject invalid operations) and sensitivity (the rule's ability to correctly identify valid operations). These indicators evaluate the performance of the rule from different perspectives.

[0228] The system sets preset thresholds for performance metrics, which serve as the admission criteria for candidate rules to be added to the rule base. Typical threshold settings are: precision ≥ 0.85, recall ≥ 0.75, false positive rate ≤ 0.15, and F1 score ≥ 0.80. Only candidate rules that simultaneously meet all threshold conditions are accepted. Setting the thresholds requires a trade-off between rule quality and rule base coverage. Too high a threshold will reject many useful rules, leading to insufficient rule base coverage; too low a threshold will accept low-quality rules, resulting in decreased system performance. System administrators can adjust the thresholds according to actual needs to find a balance between quality and coverage.

[0229] For candidate rules whose performance metrics exceed the threshold, the system adds them to the operation mode rule base. New rules are assigned a unique rule ID and given an appropriate priority, typically lower than manually created rules but higher than other automatically generated candidate rules initially. The system also sets a trial period for new rules, closely monitoring their actual performance during this period. If performance is found to be significantly lower than during validation, the rule will be adjusted or removed promptly. The trial period is usually one week to one month, during which the system collects detailed operational data on the rule, including the number of matches, accuracy, and user feedback, for final rule evaluation.

[0230] For candidate rules whose performance metrics fail to meet the threshold, the system does not discard them immediately but saves them in the candidate rule pool for further optimization. The system analyzes the reasons why the candidate rules fail to meet the threshold, such as insufficient precision or recall, or whether the matching conditions are too broad or too narrow. Based on the analysis results, the system attempts to adjust the matching conditions of the rules, such as adding additional constraints to improve precision or relaxing certain conditions to improve recall. The adjusted rules are then re-validated. If the performance improves to above the threshold, they are added to the rule base; if multiple adjustments still fail to meet the threshold, they are marked as low-quality rules and no longer considered.

[0231] S9.5: Adjusting and disabling low-performance rules Rules with accuracy below a preset threshold are adjusted or disabled, and rules with high false positive rates are downgraded or their matching conditions modified. Maintaining the rule base includes not only adding new rules but also optimizing and cleaning up existing rules to ensure the rule base remains high-quality.

[0232] The system periodically evaluates the performance of all rules, identifying rules with accuracy below a threshold. The accuracy threshold is typically set at 0.80; rules below this threshold are considered low-performance rules and require improvement. The system analyzes false positives from low-performance rules, identifying characteristic patterns that lead to these false positives. For example, a rule might filter out all .log files, but a user's application uses .log files to store important data, resulting in a false positive. The system analyzes other characteristics of these falsely identified .log files, finding that they are all located in specific directories or created by specific processes. Based on these findings, the system modifies the rule's matching conditions, adding additional constraints, such as "filtering .log files, but excluding .log files in the / app / data directory."

[0233] Rule adjustments can be made by adding constraints, modifying matching patterns, and adjusting processing actions. Adding constraints can improve rule accuracy and reduce false positives, but may decrease coverage. Modifying matching patterns can adapt to new file naming conventions or new operating modes; for example, changing the filename pattern from ".tmp" to ".tmp|*.temp" to cover more temporary file extensions. Adjusting processing actions can change the behavior of the rules; for example, changing direct filtering to delayed processing gives the system more time to observe subsequent events and make more accurate judgments. The system will verify the adjusted rules on a test set to ensure that the adjustments actually improve performance before applying them to the production environment.

[0234] For rules with a high false positive rate, the system lowers their priority. Lowering the priority means that the rule will be checked later during the matching process, while other more reliable rules will be prioritized for matching events. This method is suitable for situations where the rule itself has some value but insufficient reliability. By lowering the priority, the system can preserve the rule's functionality while reducing the impact of false positives. If the rule's performance improves subsequently, the system can restore its priority.

[0235] For rules that fail to meet performance requirements despite multiple adjustments, the system will disable them. Disabled rules are not deleted but marked as inactive and will not participate in event matching. Disabled rules are archived in the rule base for later analysis and reference. The system records the reasons for rule disabling, such as consistently low accuracy, excessively high false positive rate, or being replaced by a better rule. Administrators can view disabled rules and decide whether to re-enable them or delete them permanently.

[0236] The system also implements a rule conflict detection and resolution mechanism. A rule conflict occurs when multiple rules may match the same event, but their processing actions are inconsistent. For example, one rule determines that a file should be filtered, while another rule determines that it should be synchronized; the system needs to resolve this conflict. Conflict resolution strategies include selection by priority, selection by confidence level, and selection by rule type. Typically, the system selects the rule with higher priority; if priorities are the same, it selects the rule with higher confidence. The system records all rule conflicts, analyzes the causes of the conflicts, and adjusts the matching conditions or priorities of the rules to reduce future conflicts.

[0237] Version management of the rule base is also a crucial part of maintenance. The system creates a snapshot of each modification to the rule base, recording the modification time, content, and reason. Version management allows the system to roll back to previous rule base versions, and quickly revert to a stable version when new rules cause performance degradation. The system also supports A / B testing of the rule base, running two versions simultaneously to compare their performance and selecting the better version as the official release. This mechanism ensures that every update to the rule base is beneficial and does not degrade system performance.

[0238] Through this systematic rule base adaptive update mechanism, the system can continuously learn and improve, adapt to the ever-changing software environment and user behavior, maintain efficient and accurate file operation filtering capabilities, and eliminate the need for frequent manual intervention. Example

[0239] This embodiment details the specific implementation structure of a file operation intelligent filtering device.

[0240] like Figure 2 As shown, this embodiment provides an intelligent file operation filtering device, including an event monitoring module, a feature extraction module, a pattern matching module, a filtering decision module, and a rule update module. These modules work together to realize the complete functions described in the foregoing method embodiments.

[0241] The event listening module is responsible for real-time monitoring of file system operation events and performing preliminary filtering and preprocessing of these events. This module registers its monitoring of the target directory through file system monitoring interfaces provided by the operating system, such as inotify for Linux, ReadDirectoryChangesW for Windows, and FSEvents for macOS. When file creation, modification, deletion, or moving operations occur in the target directory, the operating system notifies the event listening module, which then receives the event notification and parses the basic information of the event.

[0242] The event listening module's internal structure comprises three sub-components: an event receiver, an event resolver, and an event buffer. The event receiver interacts with the operating system's file monitoring interface to receive raw event notifications. Since different operating systems have significantly different interfaces, the event receiver needs to adapt to various interfaces and provide a unified event reception abstraction. The event resolver parses the raw event notifications, extracting basic information such as event type, file path, and timestamp, and converts it into a unified event object format. The event buffer temporarily stores received events, employing an efficient queue data structure to support high-concurrency event writing and reading. The buffer implements a flow control mechanism: when the event generation rate exceeds the processing rate, the buffer accumulates events to prevent event loss; when the buffer is nearing full capacity, the system triggers a backpressure mechanism, pausing the reception of new events or discarding low-priority events.

[0243] The event listening module also implements event filtering, performing preliminary screening of obviously irrelevant events. For example, events in the system directory, events from hidden files, and events with specific file extensions can be filtered out during the listening phase, preventing them from entering the subsequent processing flow. This early filtering can significantly reduce the number of events that need to be processed, improving overall system performance. Filtering rules can be configured through a configuration file, allowing users to customize filtering conditions according to their actual needs.

[0244] The feature extraction module is responsible for extracting multi-dimensional features from the raw event and constructing a feature vector representation of the event. This module receives the event object from the event listening module, analyzes various aspects of the event, and extracts features in the time, file, process, and path dimensions.

[0245] The feature extraction module's internal structure comprises four sub-components: a time feature extractor, a file feature extractor, a process feature extractor, and a path feature extractor, each responsible for extracting features from different dimensions. The time feature extractor analyzes the event's timestamp, calculates the absolute time, relative time, and time interval of the event, maintains event history records, and identifies event sequences and time patterns. The file feature extractor analyzes file attributes such as name, extension, size, and permissions, extracting features such as filename patterns, file type, and file status. The process feature extractor queries operating system process information to obtain the process ID, process name, process path, and command-line arguments that triggered the event, and determines the process type based on process characteristics. The path feature extractor analyzes the complete file path, extracting features such as directory hierarchy, parent directory, and path patterns to identify the project or workspace to which the file belongs.

[0246] The feature extraction module also includes a feature caching mechanism to cache frequently accessed features and avoid redundant calculations. For example, querying process information may involve system calls, which are costly. The module caches the mapping from process ID to process information, so subsequent events of the same process can directly retrieve process information from the cache. Querying file attributes may also require accessing the file system; the module caches the mapping from file path to file attribute, reducing the number of file system accesses. The cache uses an LRU eviction policy, removing the least recently used entry when the cache is full to maintain cache effectiveness.

[0247] The pattern matching module is responsible for matching event features with the operation pattern rule base to identify the operation pattern corresponding to the event. This module receives the event feature vector generated by the feature extraction module, traverses the rules in the rule base, checks whether the event matches the triggering condition of the rule, calculates the matching confidence, and selects the best matching rule.

[0248] The pattern matching module's internal structure comprises three sub-components: a rule base manager, a matching engine, and a confidence calculator. The rule base manager is responsible for loading, storing, and managing the operational pattern rule base. The rule base is stored in a structured format, such as JSON or XML, containing complete information such as matching conditions, processing actions, priorities, and statistical data for each rule. The manager loads the rule base into memory at system startup, building an efficient index structure to support fast rule queries and matching. The manager also supports dynamic updates to the rule base; changes to the rule base take effect without requiring a system restart.

[0249] The matching engine is the core component of pattern matching, implementing the specific logic for rule matching. The engine supports multiple matching modes, including filename pattern matching, event sequence pattern matching, and process type matching. Filename pattern matching uses wildcards or regular expressions, supporting flexible filename pattern definitions. Event sequence pattern matching uses finite state machines, supporting complex event sequence recognition. Process type matching uses simple string comparison or pattern matching. The engine employs optimized matching algorithms, such as using prefix trees to accelerate wildcard matching, using NFA or DFA to accelerate regular expression matching, and using state machines to optimize event sequence matching, improving matching efficiency.

[0250] The confidence calculator is responsible for calculating the confidence score of an event matching a rule. The calculator comprehensively considers multiple factors such as feature matching degree, sequence completeness, time window compliance, and historical accuracy, using a weighted formula to calculate the final confidence score. The calculator's weight parameters can be adjusted through a configuration file to adapt to different application scenarios and performance requirements. The calculator also supports dynamic adjustment of the confidence score, adjusting the historical accuracy factor based on the actual performance of the rule, making the confidence score calculation more accurately reflect the reliability of the rule.

[0251] The filtering decision module is responsible for making filtering decisions based on pattern matching results, determining the final handling method for events. This module receives the matching results output by the pattern matching module, analyzes the processing actions of the matching rules, and generates filtering decisions by combining the correlation of events and the completeness of operations.

[0252] The filtering decision module's internal structure comprises four sub-components: a policy mapper, an event queue manager, an association analyzer, and a decision executor. The policy mapper is responsible for mapping rule processing actions to standard filtering policy types, including direct filtering, delayed processing, conditional triggering, immediate triggering, and batch triggering. Based on the rule definition and event characteristics, the mapper determines the appropriate policy type, providing a basis for subsequent decisions.

[0253] The event queue manager is responsible for managing the queue of events awaiting decision-making and maintaining events that require delayed processing or conditional triggering. The manager implements an efficient queue data structure, supporting fast insertion, querying, updating, and deletion of events. It also implements a timeout detection mechanism, periodically scanning the queues to check for timeouts and triggering mandatory decisions for timeout events. The manager supports parallel management of multiple queues; different types of events can use different queues, improving processing efficiency.

[0254] The association analyzer is responsible for analyzing the relationships between events and constructing an event association graph. The analyzer maintains a historical record of events, identifies events within the same process, file, or directory, and establishes association edges between events. The analyzer also implements causal relationship inference, inferring dependencies between events based on their type, time sequence, and file relationships. The association graph is stored using a graph data structure, supporting efficient graph query and traversal operations, such as finding all predecessor, successor, and related events of a given event.

[0255] The decision executor is responsible for executing the final filtering decision, generating synchronization tasks or ignoring events. Based on the filtering strategy type and operational integrity judgment, the executor determines the specific action. For events that are directly filtered, the executor marks the event as processed and records statistics. For events that are triggered immediately, the executor generates a synchronization task, including file path, synchronization type, priority, and other information, and submits it to the file synchronization system. For events that require delayed processing, the executor decides whether to continue waiting or trigger synchronization based on the operational integrity judgment. The executor also implements batch processing optimization, merging synchronization tasks for multiple related events into batch tasks to improve synchronization efficiency.

[0256] The rule update module is responsible for collecting system operation feedback and adaptively updating the operation mode rule base. This module receives the execution results of filtering decisions and user feedback information, analyzes rule performance, generates new rules, adjusts or disables low-performance rules, and maintains a high-quality rule base.

[0257] The rule update module's internal structure comprises four sub-components: a feedback collector, a performance analyzer, a rule generator, and a rule optimizer. The feedback collector is responsible for collecting various feedback information, including the execution results of synchronization tasks, user manual corrections, and detailed information on misjudged events. The collector provides an API interface for the file synchronization system and user interface to submit feedback data. It also implements persistent storage of feedback data, saving it to a database for subsequent analysis.

[0258] The performance analyzer is responsible for analyzing the performance metrics of rules, calculating statistical data such as precision, recall, and false positive rate. The analyzer periodically extracts data from the feedback database, groups it by rule, performs statistical analysis, and updates the performance metrics for each rule. The analyzer also implements trend analysis, tracking changes in rule performance over time and identifying rules with declining performance. The analyzer generates performance reports for administrators to view and make decisions.

[0259] The rule generator is responsible for discovering new operation patterns from unmatched events and generating candidate rules. The generator uses clustering algorithms to group unmatched events and pattern mining algorithms to extract common features, constructing matching conditions and processing actions for candidate rules. The generator also implements rule validation, testing the performance of candidate rules on historical data; only candidate rules that meet performance standards are added to the rule base.

[0260] The rule optimizer is responsible for adjusting and maintaining existing rules to improve the overall quality of the rule base. Based on performance analysis results, the optimizer identifies low-performance rules, analyzes the causes of misjudgments, and modifies the matching conditions or processing actions of the rules. The optimizer also implements rule conflict detection and resolution, identifying rules that may cause conflicts, adjusting the priority or matching conditions of the rules, and reducing conflicts. The optimizer supports disabling and archiving rules, disabling low-performance rules that cannot be improved, keeping the rule base concise and efficient.

[0261] These modules work together through well-defined interfaces to form a complete intelligent file operation filtering device. The modules communicate using message passing or event-driven methods, achieving a loosely coupled architecture that facilitates independent development, testing, and maintenance. The device supports horizontal scaling, allowing multiple instances to be deployed for parallel processing to handle large-scale file operation event streams. Example

[0262] This embodiment details a specific implementation of a computer-readable storage medium.

[0263] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the file operation intelligent filtering method described in any of the foregoing embodiments.

[0264] Computer-readable storage media can be various forms of non-volatile storage devices, including but not limited to read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, disk storage, optical disk storage, and solid-state drive (SSD). The choice of storage media depends on the specific requirements of the application scenario, such as read / write speed, storage capacity, cost, and reliability.

[0265] A computer program stored on a medium consists of two parts: executable code and data. The executable code implements each step of the file operation intelligent filtering method, including code for functional modules such as event listening, feature extraction, pattern matching, filtering decisions, and rule updates. The code can be written in various programming languages, such as C, C++, Java, Python, and Go, with the appropriate language chosen based on performance requirements and development efficiency. For performance-critical modules such as event listening and pattern matching, compiled languages ​​like C or C++ are typically used to achieve the highest execution efficiency. For logically complex modules such as rule updates, interpreted languages ​​like Python can be used to improve development efficiency and code maintainability.

[0266] The program's data section includes an operation mode rule base, configuration parameters, and statistical data. The rule base is stored in a structured format, such as JSON, XML, or binary format, and contains the complete definition of all rules. Configuration parameters, including adjustable parameters such as file monitoring directories, filtering thresholds, timeout periods, and performance metric thresholds, are stored in configuration files and can be modified by the user as needed. Statistical data, including historical performance metrics of the rules, event processing statistics, and user feedback records, are stored in a database or log files for performance analysis and rule optimization.

[0267] The program's execution flow follows the description in the aforementioned method embodiments. When the program is loaded and executed by the processor, it first undergoes initialization, including loading the rule base, reading configuration parameters, and initializing various functional modules. Then, it enters the main loop, continuously monitoring file system events. For each received event, it sequentially performs steps such as feature extraction, pattern matching, and filtering decisions to generate the final processing result. The program also periodically executes rule update tasks, analyzes feedback data, and optimizes the rule base. The program supports graceful shutdown; upon receiving a termination signal, it completes the currently processed events, saves the rule base and statistical data, and then exits safely.

[0268] The program implements a robust error handling mechanism to capture and handle potential anomalies. For example, if the file system monitoring interface fails due to insufficient permissions or system resource limitations, the program will catch the exception, log the error, and attempt reinitialization or degraded operation. During rule matching, if malformed rules or invalid regular expressions are encountered, the program will skip the erroneous rules, log warning messages, and continue processing other rules. The program also implements resource management to ensure that file handles, memory, threads, and other resources are correctly allocated and released, preventing resource leaks.

[0269] The program supports multi-threaded or multi-process parallel execution, fully utilizing the computing power of multi-core processors. Steps such as event listening, feature extraction, pattern matching, and filtering decisions can be executed in parallel across different threads, communicating through message queues or shared memory. The program uses a thread pool to manage worker threads, avoiding the overhead of frequently creating and destroying threads. The program also implements thread-safe data structures and synchronization mechanisms, such as mutexes, read-write locks, and atomic operations, ensuring the correctness of concurrent access to shared data.

[0270] The program also includes logging functionality, recording detailed system operation information, including event handling processes, rule matching results, decision-making processes, performance metrics, errors, and warnings. Logs are divided into multiple levels, such as DEBUG, INFO, WARNING, and ERROR, and users can configure the log levels to control the level of detail. Logs are output to a file or standard output, supporting log rotation to prevent log files from growing indefinitely. Logging is an important tool for system debugging, performance analysis, and troubleshooting.

[0271] Storage media can also contain program installation packages or deployment scripts, facilitating user installation and configuration. Installation packages can be in operating system-specific formats, such as .exe or .msi files for Windows, .deb or .rpm packages for Linux, and .dmg or .pkg files for macOS. Deployment scripts can automate the installation process, including dependency checks, file copying, configuration generation, and service registration, simplifying the user's deployment workflow.

[0272] By implementing the intelligent file operation filtering method as a computer program and storing it on a readable storage medium, users can easily install and run the program on various computing devices, enjoy the convenience brought by intelligent filtering, and improve the efficiency of the file synchronization system and the user experience.

[0273] It should be noted that the terms "an embodiment," "embodiment," and "exemplary embodiment" used herein do not necessarily refer to the same embodiment or example. Furthermore, these embodiments and examples do not limit the scope of the invention unless explicitly stated otherwise. In addition, the embodiments and features described herein can be combined with each other unless otherwise specified.

[0274] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0275] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. The present invention is not limited to the above embodiments. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical solutions of the present invention shall fall within the protection scope of the present invention.

Claims

1. A file system event handling method based on intelligent filtering rules, characterized in that, include: Obtain the raw file system events of the monitored directory, perform cross-platform event mapping and path standardization on the raw file system events, and obtain standardized event data; Feature extraction is performed on the standardized event data to extract time-dimensional features, file-dimensional features, process-dimensional features, and path-dimensional features, resulting in a multi-dimensional event feature vector. Based on software operation behavior pattern information, operation pattern rules including triggering conditions, matching priorities and processing actions are constructed to obtain an operation pattern rule library. Based on the multi-dimensional event feature vector and the operation pattern rule base, pattern matching is performed on the event sequence and the matching confidence is calculated to obtain the pattern matching result. Based on the pattern matching results, determine the filtering strategy type and perform corresponding filtering processing on the events, and output the event filtering decision results. Based on the event filtering decision results and operational statistics, the filtering effect is analyzed and the time window parameters and rule weight parameters are dynamically adjusted to obtain optimized system parameters.

2. The method according to claim 1, characterized in that, The original events of the file system are subjected to cross-platform event mapping and path normalization processing to obtain standardized event data, including: Obtain the event type, timestamp, and file path of the original events in the file system, map the event types of different operating systems to a unified internal event type, and obtain the mapped event type; The file paths in the original events of the file system are processed by unifying path separators and converting absolute paths to obtain normalized paths. Based on the mapped event type, the normalized path, and the timestamp, the standardized event data is generated.

3. The method according to claim 1, characterized in that, The extracted time dimension features include: Based on the timestamps in the standardized event data, the time offset of the event occurrence time relative to the monitoring start time is calculated to obtain the absolute time characteristics; Calculate the time interval between adjacent events, identify fast consecutive events with time intervals less than a preset threshold, and obtain relative time features; By statistically analyzing the frequency and density of events occurring within a preset time window, periodic and sudden events can be identified, and time-series pattern characteristics can be obtained.

4. The method according to claim 1, characterized in that, Extracting file dimensional features includes: The file paths in the standardized event data are parsed to extract file names, extensions, and directory levels, thus obtaining path parsing features. The filenames are subjected to pattern recognition to identify temporary file suffixes, temporary file prefixes, and intermediate compilation file patterns, thereby obtaining filename pattern features; Obtain information on file size and attribute changes to obtain file attribute characteristics.

5. The method according to claim 1, characterized in that, Extracting process dimension features includes: Obtain the process identifier and process name that triggered the original event of the file system, and obtain the basic information of the process; Based on a preset mapping table between process names and process types, the process names are identified to identify editor processes, compiler processes, version control tool processes, and office software processes, thereby obtaining process type characteristics. The process behavior characteristics are obtained by counting the number of operations and the set of files operated on by the same process within a preset time window.

6. The method according to claim 1, characterized in that, Based on software operation behavior pattern information, operation pattern rules are constructed, including triggering conditions, matching priorities, and processing actions, resulting in an operation pattern rule library, including: Based on the file operation sequence information of the editor software, an editor operation mode rule is constructed that includes event sequence triggering conditions for swap file creation, original file modification and swap file deletion, and the processing action of the editor operation mode rule is set to only synchronize the last modification of the original file. Based on the file operation sequence information of the compiler software, a compiler operation mode rule containing the triggering conditions for the batch creation of intermediate files is constructed, and the processing action of the compiler operation mode rule is set to delayed synchronization. Based on the file operation sequence information of the version control tool, a version control operation mode rule is constructed, which includes event sequence triggering conditions for lock file creation, lock file modification and lock file renaming, and the processing action of the version control operation mode rule is set to only synchronize the final state. Based on the file operation sequence information of office software, an office software operation mode rule containing temporary file prefix pattern trigger conditions is constructed, and the processing action of the office software operation mode rule is set to filter temporary files. Based on the file operation sequence information of the application's atomic write, an atomic write operation mode rule is constructed, which includes event sequence triggering conditions for temporary file creation, data writing, and renaming overriding. The processing action of the atomic write operation mode rule is set to wait for the renaming to complete and then synchronize. The editor operation mode rules, the compiler operation mode rules, the version control operation mode rules, the office software operation mode rules, and the atomic write operation mode rules are sorted and stored according to matching priority to obtain the operation mode rule library.

7. The method according to claim 1, characterized in that, Based on the multi-dimensional event feature vector and the operation pattern rule base, pattern matching is performed on the event sequence and the matching confidence is calculated to obtain the pattern matching result, including: The multi-dimensional event feature vector is represented in a set-based manner. The features of each event are converted into a set of feature indices. The union of the feature index sets of all events in the event sequence is taken as the complete set to obtain the complete set of event features. Each rule in the operation mode rule base is represented by a coverage set, and the set of feature indexes that each rule can interpret is determined to obtain the rule coverage set; The rules in the operation mode rule base are paired for compatibility judgment. A rule compatibility graph is constructed based on the intersection of the rule coverage set and the semantic conflict relationship. The nodes of the compatibility graph represent rules, and the edges represent the conflict relationship between rules. Based on the complete set of event features, the rule coverage set, and the rule compatibility graph, the pattern matching problem is transformed into a minimum set coverage problem with compatibility constraints. A parameterized algorithm is used to solve for the minimum rule subset that satisfies the coverage integrity and compatibility constraints, thereby obtaining the optimal rule set. Based on the optimal rule set, rule matching is performed on each event in the event sequence, the explanation score of each rule for the event is calculated, and the rule with the highest explanation score is used as the matching rule for the event to obtain the pattern matching result.

8. The method according to claim 1, characterized in that, Based on the multi-dimensional event feature vector and the operation pattern rule base, pattern matching is performed on the event sequence and the matching confidence is calculated to obtain the pattern matching result, including: Linear feedback shift register encoding is performed on each dimension feature in the multi-dimensional event feature vector to encode the time dimension feature, file dimension feature, process dimension feature and path dimension feature into fixed-length binary state values, and the binary state values ​​of each dimension are combined to obtain the event feature code. Based on the preset sliding window size, the event feature encoding is subjected to rolling hash calculation, and the incremental hash update during window sliding is achieved by utilizing the shift characteristics of the linear feedback shift register to obtain the window hash value. For each rule in the operation mode rule base, generate a pattern signature, calculate the signature hash value based on the linear feedback shift register encoding of the typical event sequence of the rule, and set a matching tolerance threshold to obtain the pattern signature base; Based on the window hash value and the pattern signature library, the Hamming distance between the window hash value and each pattern signature is calculated. The rules corresponding to the pattern signatures whose Hamming distance is less than the matching tolerance threshold are taken as candidate matching rules to obtain a set of candidate matching rules. Calculate the matching confidence score for each rule in the candidate matching rule set, select the rule with the highest matching confidence score as the final matching rule, and obtain the pattern matching result.

9. The method according to claim 1, characterized in that, Based on the pattern matching results, the filtering strategy type is determined and corresponding filtering processing is performed on the events. The event filtering decision results are output, including: Based on the processing actions of the matching rules in the pattern matching results, the filtering strategy type of the event is determined. The filtering strategy type includes direct filtering, delayed processing, conditional triggering, immediate triggering, and batch triggering. For events whose filtering strategy type is delayed processing or condition triggering, the event is added to the event waiting queue, and the event information, the time of adding to the queue, and the waiting timeout are recorded to obtain the event queue to be decided. The events in the queue of events to be decided are analyzed for correlation to identify events generated by the same process, multiple operation events of the same file, and related operation events under the same directory. The causal dependencies between the events are then constructed to obtain an event correlation graph. Based on the event association graph, the key start and end events of the event sequence are identified, and it is determined whether the operation sequence has been completed, thus obtaining the operation integrity judgment result. Based on the filtering strategy type, the event association graph, and the operation integrity judgment result, events of the direct filtering type are ignored, events of the immediate trigger type are synchronously triggered, events of the delayed processing type whose operation has been completed are synchronously triggered, and events whose operation has not been completed continue to wait, thus obtaining the event filtering decision result.

10. The method according to claim 8, characterized in that, The pattern signature library is updated through adaptive signature learning, including: Collect the event feature codes of the event sequence and the corresponding pattern matching results, count the number of matches and the matching accuracy of each rule, and obtain rule matching statistics. For rules with a matching accuracy higher than a preset accuracy threshold, the linear feedback shift register encoding of the successfully matched event sequence is used as a positive sample. The average Hamming distance between the positive sample and the existing signature is calculated. If the average Hamming distance is less than the matching tolerance threshold, the existing signature is updated by weighted average. For rules with a matching accuracy rate lower than a preset accuracy threshold, the event sequence characteristics of mismatches are analyzed, and the matching tolerance threshold of the corresponding signature in the pattern signature library is adjusted or the signature hash value is updated to obtain an updated pattern signature library.

11. A file system event processing device based on intelligent filtering rules, characterized in that, include: The event acquisition module is used to acquire raw file system events of the monitored directory, perform cross-platform event mapping and path standardization processing on the raw file system events, and obtain standardized event data. The feature extraction module is used to extract features from the standardized event data, including time dimension features, file dimension features, process dimension features and path dimension features, to obtain a multi-dimensional event feature vector; The rule base management module is used to construct operation pattern rules, including triggering conditions, matching priorities, and processing actions, based on software operation behavior pattern information, to obtain the operation pattern rule base; The pattern matching module is used to perform pattern matching on the event sequence and calculate the matching confidence based on the multi-dimensional event feature vector and the operation pattern rule base to obtain the pattern matching result. The intelligent filtering module is used to determine the filtering strategy type based on the pattern matching result, perform corresponding filtering processing on the event, and output the event filtering decision result. The parameter optimization module is used to analyze the filtering effect and dynamically adjust the time window parameters and rule weight parameters based on the event filtering decision results and operation statistics to obtain optimized system parameters.

Images