CN101819525A

CN101819525A - 用于查找系统中应用的配置文件的方法和设备

Info

Publication number: CN101819525A
Application number: CN200910126105A
Authority: CN
Inventors: 邱杰; 腾启明; 刘天成; 钟虓
Original assignee: International Business Machines Corp
Current assignee: IBM China Co Ltd
Priority date: 2009-02-27
Filing date: 2009-02-27
Publication date: 2010-09-01
Anticipated expiration: 2029-02-27
Also published as: US20100223306A1; US8612389B2; CN101819525B

Abstract

本发明提供了一种用于查找系统中应用的配置文件的方法和设备，其中方法包括获取关注的应用的进程标识符；将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定配置文件是所关注的应用的配置文件。通过本发明可以实现自动地查找到应用的配置文件，从而可以对其进行监视，并能有效并准确地发现应用的配置文件的改变，以便用户能够方便地执行各种后续操作(例如记录、恢复或备份等)。

Description

用于查找系统中应用的配置文件的方法和设备

技术领域

本发明一般地涉及应用的配置文件。更具体地，本发明涉及用于查找系统中应用的配置文件的方法和设备。

背景技术

应用的配置文件是专用于记录和设定应用的相关配置的一类文件。一些应用只是在启动的时候才读取相应的配置文件，而另一些应用则是定期的或者在特定的条件下重新读取相应的配置文件，并作用到当前启动的应用。目前，应用的配置文件主要包括以下几种类型，一种配置文件类型是文本文件，即应用的配置文件是以纯文本的形式编写成，另一种配置文件类型是运行的相关静态/动态加载库，例如用户的动态链接库(dll)，由于对动态链接库的改变也会影响到与它相关的应用的配置文件，因此也将动态链接库归类于此种类型的配置文件。另外还有一种配置文件类型是视窗操作系统(Windows)所特有的注册表。

通常，计算设备中多个应用的上述各种类型的配置文件的改变会对该应用运行时的可靠性、可用性以及可伸缩性产生影响，而其中对某些关键配置文件的错误修改可能会严重影响到应用的运行，并由此可能产生不可恢复的故障。因此，用户要对运行的应用进行监视，尤其要对应用的配置文件是否发生改变进行监视，以便尽可能快的发现这样的配置文件的改变，从而在当该改变对应用的可靠性、可用性以及可伸缩性可能造成影响或业已造成影响时，能够及时地记录该应用的配置文件的改变，对该应用的配置文件的改变进行相应的处理，从而消除潜在的或业已存在的影响。

然而，在实时地监视用户对应用的配置文件进行配置并导致应用的原有配置发生改变的操作前，自动地查找到应用的配置文件是项很困难的任务，原因在于通常应用的配置文件的类型和数量众多，且分散在不同的系统中的不同位置处，自动地查找出配置文件往往难以实现。其次，尽管对应用进行配置是很平常的操作，但当对大量的应用进行配置时，由该配置操作所形成的数据量将是庞大的，而要监视如此庞大的数据量，对运行应用的系统的处理能力、计算能力和存储能力都提出很高的要求，这无疑增加了监视应用配置的改变的成本。

现有的对应用的配置文件进行监视的解决方案包括以下几种，一种是对整个系统的所有配置文件的改变进行监视，换句话说，系统中所有的配置文件均被看做与所关注的应用相关。一旦应用的运行发生错误，则可以检查所有配置文件中发生改变的配置文件，以便进行错误恢复，但这样的监视代价是也相当高的。另一种是对特定的配置文件进行监视，即抓取与该应用所相关的所有配置文件，但如何抓取和分析该应用的所有配置文件则由用户自己手动地进行，这无疑增加了用户的工作量。

因此，需要一种方法和设备，其用于自动地查找运行的应用的配置文件，继而对该配置文件进行监视，从而准确确定该配置文件是否发生改变。另外，应当注意到的是在本发明中，术语“配置文件”应该做最宽泛的理解，即对系统中应用的运行和操作会产生影响的文件在本发明的精神和范围下都属于该应用的配置文件。

发明内容

本发明要解决的技术问题是提供一种能够自动地查找应用的配置文件，并且进一步在自动地查找到这样的配置文件后，通过对该应用的配置文件进行监视，从而高效并准确地发现该应用的配置文件的改变的方法和设备。

为了解决上述的技术问题，本发明的一个方面提供一种用于查找系统中应用的配置文件的方法，所述方法包括以下步骤：获取关注的应用的进程标识符；将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

本发明的另一方面提供一种用于查找系统中应用的配置文件的设备，所述设备包括：获取装置，用于获取关注的应用的进程标识符；比较装置，用于将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；确定装置，用于当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

通过使用本发明提供的用于查找系统中应用的配置文件的方法和设备，从应用启动时刻起直到当前时刻能够持续地自动找到应用的配置文件并且借此跟踪应用读取配置文件的操作，进一步准确地发现该应用在运行时刻配置文件发生的改变，从而便于用户对由于配置文件改变而导致应用运行异常进行快速的恢复。

附图说明

通过以下结合附图的说明，并且随着对本发明的更全面了解，本发明的其他目的和效果将变得更加清楚和易于理解，其中：

图1a是示意性示出根据本发明的实施方式的应用之间由于配置文件而存在相关性的示图；

图1b是示意性示出根据本发明一个实施方式的用于自动地查找应用的配置文件的配置文件列表(CFL)的跟踪器的操作架构图；

图2是示意性示出根据本发明一个实施方式的系统架构图；

图3是示意性示出根据本发明一个实施方式的系统操作流程图；

图4是示意性示出根据本发明一个实施方式的CFL跟踪器在Linux操作系统上执行操作时的流程图；

图5是示意性示出根据本发明一个实施方式的CFL跟踪器在Windows操作系统上执行操作时的流程图；

图6是示意性示出根据本发明一个实施方式的将内核态的数据传送到用户态下的架构图；

图7是示意性示出根据本发明另一实施方式的将内核态的数据传送到用户态下的架构图；

图8是示意性示出结合缓冲区的布置而将在内核态中收集的配置文件数据送入到用户态中的操作流程图；

图9是示意性示出根据本发明一个实施方式的用于自动地查找系统中应用的配置文件的方法的流程图；以及

图10是示意性示出根据本发明一个实施方式的用于自动地查找系统中应用的配置文件的设备的框图；

在所有的上述附图中，相同的标号表示具有相同、相似或相应的特征或功能。

具体实施方式

下面将结合附图详细描述本发明的实施方式。

图1a是示意性示出根据本发明的实施方式的应用之间由于配置文件而存在相关性的示图。在该图中以Windows操作系统为例，正如本领域技术人员所知，在Windows操作系统中，存在由COM管理器所管理的多个COM组件，即图中所示出的COM实例(其可以处于内核态或用户态中，仅为了示意性的目的，在该图中示出位于内核态的一个COM实例)，其对于操作系统而言是另外的调度实体。在实际的运行中，应用(其处于用户态)可能要调用和使用到多个COM组件。如图中所示，应用的运行与其配置文件A和B直接相关，而COM实例的运行依赖于其自身的配置文件C。

如果应用不使用COM组件，那么在本发明的一个最基本的实施例中，只关注与应用自身直接相关的配置文件A和B，通过监视应用的进程对文件的访问来定位与应用相关的配置文件。该基本的实施例已经能够自动地查找应用的配置文件。

但是，在如图1a所示的更加一般的情况下，由于配置文件C的改变会影响到COM实例的实际运行，则当应用调用COM实例时，改变的COM实例的配置文件也可能会对应用的运行产生影响。因此，该最基本的实施例可能存在的问题在于，忽略了对COM实例的配置文件C的关注，即忽略与应用间接相关的配置文件的改变。在对该基本实施例的进一步的改进中，不仅要跟踪与应用直接相关的配置文件(例如图1a中的配置文件A和B)的改变，而且还要跟踪与应用间接相关的配置文件(例如图1a中的配置文件C)的改变，从而全面地监控应用的配置变化。尽管在该图中以Windows操作系统为例进行了示例性的描述，但本领域技术人员在本发明的教导下能够理解到当在Linux操作系统的情况下，将类似地通过利用进程间通信机制来获取与所关注的应用相关的其他应用的进程号(PID)，从而不仅能够跟踪与应用直接相关的配置文件，也即运行的应用所直接相关的配置文件，还要跟踪与运行的应用有关的各种服务进程或线程所相关的配置文件，也即运行的应用所间接相关的各种配置文件。

图1b是示意性示出根据本发明一个实施方式的用于自动地查找应用的配置文件的配置文件列表(CFL)的跟踪器的操作架构图。如图中所示，应用App01、App02和COM实例01位于用户态中，而COM实例02、COM管理器、钩子(Hooker)交换器、Hooker以及结果交换器位于内核态中。需要指出的是尽管本领域技术人员知道图中所示出的COM实例(组件)和COM管理器是Windows操作系统所特有的，但在这里对二者的描述仅仅是示例性的，并不会对本实施方式的操作构成任何的限制，而关于本发明的方法如何在Windows操作系统上的实现将在下文中进行具体地描述。

在操作开始进行前，首先给将要运行的应用App01安装Launcher模块来辅助该应用App01的启动。当实际启动应用App01时，首先由Launcher模块将应用App01的启动暂时中断，并且接着获得系统为该应用所分配的PID和/或TID(线程号)。

在步骤11中，Launcher模块启动处于内核态中的Hooker交换器并且将该应用的PID/TID注册到该Hooker交换器。

在步骤12中，用于记录哪些进程使用到哪些COM实例的COM管理器将记录的App01所使用的COM实例01和COM实例02的PID和/或TID注册到Hooker交换器。如上所述，COM实例01和COM实例02可能进一步调用其他的COM。所述COM管理器将COM实例01和COM实例02所进一步用到的COM实例的PID和/或TID也注册到Hooker交换器。依次类推，直到应用App01本身的PID和/或TID、App01直接用到的COM实例的PID和/或TID以及，如果有的话，App01间接用到的COM实例的PID和/或TID都被注册到Hooker交换器。

尽管在该图中示例性示出COM实例01位于用户态中而COM实例02位于内核态中，但本领域技术人员根据本发明的教导能够理解各个COM实例位于用户态还是位于内核态对于本发明原理的阐述不是重要的。

尽管此处以Windows操作系统中的COM管理器为例记录与应用App01有关的进程(即COM实例01和02)，但COM实例只是Windows操作系统中特有的一种进程形式。COM实例的本质是进程。无论是在Windows中还是在另外的操作平台下(例如Unix或Linux)，Hooker交换器可以直接记录与应用App01相关的进程的PID。例如，如果应用的进程与某个进程甲通信，那么进程甲的PID就是与应用App01相关的PID。如果进程甲又与进程乙通信，那么进程乙的PID也是与应用App01相关的PID。这里的通信需要作最广义的理解，即只要两个进程之间存在关联关系，例如共享同一文件、存在管道、通过消息交换数据、存在调用关系等，都认为这两个进程之间通信。

发现两个进程之间存在通信有很多方式。例如，通过对进程创建操作(fork)进行拦截，可以得到由进程创建的所有子进程的PID，进程及其子进程视为存在通信。又例如，对于进程通过有名管道和内存映射(mmap)进行通信的情况。由于这两种通信都以文件描述符为路径对共享区域进行访问，所以可以通过对文件打开操作(sys_open)进行拦截，如果发现两个进程打开同样的文件，则这两个进程之间视为存在通信。再例如，对于进程通过共享内存(IPC sharedmemory region)进行通信的情况，由于进程通过ftok函数得到key访问共享内存，所以可以对ftok函数进行拦截，如果发现两个进程调用ftok得到的key值相同，则认为这两个进程存在通信。

当然，考虑到灵活性，可以设置一通信距离门限。通信距离指示了其他进程与应用的进程相关的程度。如上面的例子，进程甲直接与应用的进程通信，则通信距离为0；进程乙又与进程甲通信，而不与应用的进程通信，则进程乙与进程甲的通信距离为0，进程乙与应用的进程的通信距离为1。设置通信距离门限，使得只将与应用的进程的通信距离小于该门限的进程的PID被注册到Hooker交换器。如上面的例子，假设所述通信距离门限被设置为1，则只有应用的进程的PID和进程甲的PID被注册到Hooker交换器；假设所述通信距离门限被设置为0，则只有应用的进程的PID被注册到Hooker交换器

在步骤13中，Hooker交换器将所收集的与应用App01有关的PID的数据(其可实现为待监视应用PID列表)送入到Hooker中。接着，在本实施方式中引入的Hooker会拦截系统中所有应用的进程或线程对配置文件执行的打开操作、读操作和写操作等操作。接着，Hooker检查这些应用的PID或TID是否记录在监视列表中，如果这些进程的PID或TID存在于监视列表中，即其是用户所关注的应用的PID或TID，则Hooker接着获取这些进程或线程所要执行操作的配置文件的相关信息，例如配置文件的文件名或可以指代配置文件的各种信息，即确定这些配置文件是所关注应用的配置文件。

接着在步骤14中，Hooker将提取的配置文件的相关信息存储到结果交换器中，例如可以实现为配置文件名列表等信息。接着在步骤15中，Hooker将调用内核应用程序接口(API)来执行该进程或线程实际的配置文件打开操作、读操作或写操作。在步骤16中，Launcher模块可以周期性地从结果交换器中提取配置文件相关信息数据，并且对该结果交换器中的配置文件相关信息数据(如配置文件名列表数据)进行清除操作。可以看出，结果交换器中的配置文件相关信息数据随着系统中应用的运行而动态地变化。需要指出的是上述的TID在PID已知的情况下不是必需的，因为只有在当PID可能未知的情况下，才通过TID来获得该应用的PID，在本申请文件中，不特别区分PID和TID，而是统称为进程标识符。此外，为了简单起见，本申请文件也不特别区分应用和该应用运行时的进程。总之，通过CFL跟踪器的上述操作就自动地得到了用户关注的应用的配置文件列表。

这里要指出的是尽管在本发明中利用了应用的TID或PID来对应用进行标识，但本领域技术人员能够理解TID或PID的使用仅仅是示例性的而非限制性的，能够标识应用的任何适宜的标识符在本发明的精神和范围下都是可以的。另外，本实施方式中的Launcher模块和Hooker也仅仅是示例性的而非限制性的，本领域技术人员根据本发明的教导可以采用任何其他合适的手段来实现二者的功能，包括利用其他具有相同功能的模块或函数。

图2是示意性示出根据本发明一个实施方式的系统架构图。如图中所示，该系统包括版本控制库(VCR)管理器和CFL跟踪器，其中VCR管理器用于对系统中的所有配置文件进行监视并记录其改变，而CFL跟踪器用于查找系统中用户所关注的应用的配置文件的列表。具体地，如图中左部所示，处于操作系统(例如图中所示出的Windows或Linux操作系统)中内核态的Hooker监视应用对操作系统内所有文件(包括本发明范围内的对应用运行产生影响的配置文件)的写操作，并且在发生这样的写操作时，Hooker截获应用的写操作动作(即，写操作事件)，从而确定该应用将对哪些配置文件执行写操作，以及如何去执行这样的写操作。接着，Hooker将查找的待被执行写操作的配置文件提交给VCR管理器。在VCR管理器中，首先由文件分类器对查找的配置文件进行分类，例如将发现的配置文件分类成二进制文件(其包括动态链接库文件)、文本文件、注册表文件等类别。当二进制文件数量较多，而类别又较少时，在本发明中可选地增加哈希器，用于对这些二进制文件进行哈希映射，以便对这些文件进行重新排列以得到更有效的分类。接着文件调度器利用进程或线程操作将分类后的配置文件调度后送入到文件过滤器。在该文件过滤器中，将分类后的配置文件与CFL跟踪器中生成的配置文件列表进行匹配(即比较)，如果发生改变的配置文件不在该列表中，也即系统中执行写操作的配置文件并不是用户所关注的应用的配置文件，则不对该配置文件的改变做任何处理。如果发生改变的配置文件在该列表中，也就是说该改变的配置文件是用户所关注的，则由文件提取器将该发生改变的配置文件提取后放入到配置版本/索引/快照模块中，以便做进一步的处理，例如记录该配置文件的版本号或者对其进行备份，该操作可能是增量的或者是海量的。可选地，由VCR管理器就配置文件的改变向用户进行反馈，例如通过图形用户接口(GUI)向用户提供配置改变或比较的视图或直接向用户提醒或警告。

图3是示意性示出根据本发明一个实施方式的系统操作流程图。在该系统操作流程图中，左半部分流程图示出系统架构图中VCR管理器的操作流程，而右半部分流程图示出系统架构图中CFL跟踪器的操作流程。这里首先描述涉及VCR管理器的操作流程，正如前面所提到的，在步骤30中，Hooker首先对整个系统内所有应用执行的配置文件“写操作”进行拦截，在成功拦截后，在步骤31中，将应用所涉及写操作的配置文件的相关数据提交给VCR管理器，该相关的数据例如可以包括用户名、文件全路径(包括注册表文件)、时间戳(当前操作的时间点)，而将该数据提交给VCR管理器可以由新的线程、后台进程(或线程)或另一进程来执行。接着流程前进到步骤32中，在该步骤中，对相关的文件类型进行分类，例如前面所提到的分类成文本文件、二进制文件(包括动态链接库文件)、注册表文件。在步骤33中，文件调度器对文件数据提取任务进行调度以将文件相关信息送入到文件过滤器中，此时操作流程进入到匹配处理(即下面将详细描述的步骤37中的处理)。

为了便于理解整个系统的操作流程，现在来描述系统架构图右边的CFL跟踪器的操作流程。由于已经在上文中结合图1对CFL跟踪器的操作步骤进行了详细的描述，此处仅进行简略的描述。首先在步骤34中，CFL跟踪器对监视的应用进行处理，其中包括使用Launcher模块来启动要监视的应用(即用户所关注的应用)，并且Hooker交换器、Hooker以及结果交换器执行上面结合图1所详细描述的操作。在步骤35中，CFL跟踪器在执行步骤34中的所有操作后，获得与所关注的应用相关的所有待被执行操作(例如打开操作、读操作和写操作)的配置文件列表，可选地，在步骤36中，用户可以手动去除不关心的配置文件，例如类似日志文件的此类文件，因为应用尽管会对此类文件进行写操作，但这类文件对应用的运行并不会产生太大的影响。接着在步骤37中，CFL跟踪器将得到的配置文件列表送入到VCR管理器中的文件过滤器，由文件过滤器执行匹配操作以滤除用户不关注的配置文件，该匹配操作例如通过过滤路径、过滤文件或以命名模式过滤文件来实现。接着流程前进到步骤38，在该步骤中文件提取器提取文件过滤器滤除后的文件列表中的配置文件以便进一步的处理，优选地，可以对得到的配置文件进行版本控制(cvs)处理，例如对匹配后的文本文件、具有摘要的二进制文件、以及哈希映射后的注册表文件进行版本管理操作。可选地，可以就涉及上述配置文件改变的具体细节来通知或警示用户，例如通过配置文件改变历史视图、配置文件比较视图等图形界面来向用户通知或警示。

图4示意性示出根据本发明一个实施方式的CFL跟踪器在Linux操作系统上执行操作时的流程图。为了便于理解本发明，在该图中将操作划分成在用户态中的操作流程和在内核态中的操作流程。首先在左侧用户态的步骤41中，借助Launcher模块来启动应用，并且在利用Launcher模块启动应用后，相应地获得该应用的PID并且令该应用保持等待(即先中断应用的运行)。接着在步骤42中，Launcher模块触发Hooker交换器，即将Hooker交换器作为模块加载进内核态中，该加载操作只需在初次使用Hooker交换器时进行，即在先前的操作中如果已经加载过Hooker交换器，则其已经位于内核态中。接着在内核态中，在步骤43中，Hooker交换器将与应用的进程相关的进程的PID注册到监视列表中。接着流程前进到步骤44，在该步骤中，Hooker交换器将在内核态的某个路径下创建relay存储区，该relay存储区专用于存储在结果交换器和Launcher模块之间交换的数据(即与待运行的应用相关的配置文件名列表数据)，而Launcher模块在Hooker交换器创建relay存储区后将利用poll()函数在此处等待获取数据，如左侧流程图中的步骤45所示。在步骤46中，Hooker交换器使用在Linux平台中所具有的jProbe或者kProbe来注入Hooker，从而在步骤47中，注入的Hooker对系统中所有活跃的应用对配置文件的打开、读或写操作进行拦截。在步骤48中，Hooker通过current指针来指向当前进程的数据结构，该数据结构中保存有应用的PID，从而Hooker通过current指针获得应用的PID。在步骤49中，Hooker将当前获得的各个PID与先前的监视列表中的PID进行比较，如果Hooker当前获得的PID存在于该监视列表中，则在步骤50中，Hooker获得PID和该文件路径名(即，进程将要执行打开、读或写操作的配置文件)并将数据送入到结果交换器。在步骤51中，结果交换器将数据结构化(封装)，并且将结构化的数据写入进relay存储区中。接着在步骤52中，Hooker调用内核操作来完成当前应用对配置文件的打开、读或写操作。在步骤49中，如果Hooker将当前获得的PID与先前的监视列表中的PID进行比较后发现该PID并不在要求监视的列表中，即并非用户关注的应用所执行的操作，则直接前进到步骤52中，由Hooker调用内核操作以完成应用对配置文件的打开、读和写操作。而在该流程图左侧的步骤53中，Launcher模块将通过PID从relay存储区提取由结果交换器所写入的数据，即将要被执行操作的配置文件列表，并且在提取后，可选地，由relay的API(应用程序接口)向内核通知relay中的数据将被清空。接着在步骤54中，Launcher模块在应用退出时解除该应用的PID注册。

图5示意性示出根据本发明实施方式的CFL跟踪器在Windows操作系统上执行操作时的流程图。类似于图4，为了便于理解本发明，在该图中同样将操作划分成在用户态中的操作流程和在内核态中的操作流程。首先在左侧用户态的步骤61中，Launcher模块辅助启动应用，并在Launcher模块启动应用后，获得该应用的PID并且令该应用保持等待(即先中断应用的运行)。接着在步骤62中，Launcher模块触发Hooker交换器，即将Hooker交换器加载进内核态中并且初始化为文件过滤驱动器，该加载操作同样只需在初次使用Hooker交换器时才进行。接着进入内核态，在步骤63中，Hooker交换器将与应用的进程相关的进程的PID注册到监视列表中。接着流程前进到步骤64，在该步骤中，Hooker交换器在内核态下创建mapped存储区，该mapped存储区专用于存储在结果交换器和Launcher模块之间交换的数据，而Launcher模块在Hooker交换器创建mapped存储区后将利用poll()函数在此处等待获取数据，如左侧流程图中的步骤65所示。在步骤66中，同样注入Hooker，不同于Linux平台的是，在Windows平台下，Hooker可以实现为IRP_MJ_CREATE调用的回调函数。在步骤67中，Hooker同样拦截系统中所有应用对配置文件的打开、读或写操作。接着在步骤68中，Hooker通过调用GetCurrentProcessId()函数来获得当前将要执行上述操作的应用的PID。在步骤69中，Hooker将当前获得的PID与先前的监视列表中的PID进行比较，如果Hooker当前获得的PID存在于该监视列表中，则在步骤70中，Hooker将利用PID将该文件路径名(即，进程将要执行打开、读或写操作的文件的路径名)送入到结果交换器中。在步骤71中，结果交换器将数据结构化，并且将结构化的数据写入进mapped存储区中。接着在步骤72中，Hooker调用内核操作来完成对配置文件的打开、读或写操作。如果在步骤69中，Hooker将当前获得的PID与先前的监视列表中的PID进行比较后发现该PID并不在要求监视的列表中，则直接前进到步骤72中来由Hooker调用内核操作完成对应用的配置文件的打开、读或写操作。而在该流程图左侧的步骤73中，Launcher模块将通过PID从mapped存储区提取由结果交换器所写入的数据，即将要被执行操作的配置文件列表，并且在提取后可选地将mapped存储区中的数据清空。接着在步骤74中，Launcher模块在应用退出时解除该应用的PID注册。

图6示意性示出根据本发明一个实施方式的将内核态的数据传送到用户态下的架构图。正如本说明书前面所提到的，在当前的操作系统架构中通常将系统分为内核态和用户态，而当数据吞吐量很大时，如何高效地执行内核态和用户态之间数据的交换也是需要解决的问题。对于本发明，为了实现将在内核态中由结果交换器所收集的配置文件列表数据高效快速地传送到处于用户态的Launcher模块以便由其将结果最终送入到VCR管理器的文件过滤器中，本发明的示例性实施方式提出通过对Hooker交换器进行设备的I/O(输入/输出)控制，可以在内核态中对每个应用(如图中示例性示出的应用App01、App02和App03等)所得到的相关配置文件列表数据分配缓冲区(即上文中所提到的relay和mapped存储区)，CPU1和CPU2通过调用Result_Write()函数将每个应用(如图中的应用App01)的所有相关配置文件列表数据写入到各自的缓冲区中，而同时在用户态中，对每个应用的相关配置文件列表也相应的分配缓冲区，并且利用存储区映射方法将上述每个应用所具有的内核态缓冲区和用户态缓冲区进行关联。这样，在内核态缓冲区中存储有应用的结果时，即所关注的配置文件列表数据时，通过上面所提到的存储区映射方法，可以直接将结果送入到用户态下的各自应用缓冲区中，从而Launcher模块可以通过调用Read()函数将配置文件列表数据读取并传送给系统架构图中所示出的文件过滤器。上述的操作从原理上来讲就是按进程来进行组织数据的存放，在内核态产生数据后，将产生的数据按照不同的进程分类进行存放，数据读取程序可在用户态直接读出特定进程的数据，从而方便用户态数据处理的进行。需要指出的是，尽管在图6中分别在内核态和用户态示出缓冲区，但本领域技术人员能够理解这里的内核态和用户态中的缓冲区划分仅仅是逻辑上的划分，其在物理上可以占用存储区中的相同空间。

图7示意性示出根据本发明另一实施方式的将内核态的数据传送到用户态下的架构图。在该实施方式中，同样通过对Hooker交换器进行设备的I/O(输入/输出)控制，从而针对不同的中央处理器(CPU)分配属于CPU各自的结果缓冲区(即用于存储与CPU上运行的应用相关的配置文件列表数据的缓冲区)，例如在内核态中针对CPU 1分配CPU1结果缓冲区，针对CPU 2分配CPU2结果缓冲区，而针对CPU3分配CPU3结果缓冲区，同样也在用户态下分配相应的结果缓冲区，并且通过缓冲区映射方法将分别对应的结果缓冲区进行关联。该实施方式的上述操作从原理上讲就是按处理器来组织进行数据的存放，每个中央处理器在内核态中有自己独占的内存缓冲区，所有产生于这个处理器上的数据(如本发明中的相关配置文件列表数据)都放在这个内存缓冲区中。应用在用户态中读出数据后，再按其属于哪个进程进行分类。因为任意时刻，每个中央处理器上只有一个线程在运行，所以在内核态中对数据进行存储时不会出现写数据的竞争，方便在内核态中的数据存储。

图8是示意性示出结合缓冲区的布置而将在内核态中收集的配置文件列表数据送入到用户态中的操作流程图。如图中所示，为了便于存储从内核态获得的数据，根据本发明的实施方式，在结果缓冲区的开始处记录了有关该缓冲区总的大小、缓冲区划分的存储块(chunck)的大小以及预留空间，接着将剩余的存储空间划分成多个chunck，每个chunck的起始处包括各自的标识字段，如图8右侧的框图示出。优选地，本发明利用三个字段来标识每个chunck，其中前两个字段组合起来表示该chunck的状态，例如00表示该chunck是空的，即可以被写入数据，01表示该chunck正在被写入并且其他的写入/读取操作将被禁止，11表示该chunck处于过渡状态，其将改变到下一状态(例如10或01状态，取决于具体的存储操作)，10表示数据已经准备好并被写入了。第三个字段用于表示短时间戳标志位(TS)，用于表示写入到该chunck中的数据的时间。下面描述图8左侧的存储流程图。首先在步骤80，结果交换器准备向内核态中的缓冲区写入数据，例如得到的应用相关配置文件列表数据。在步骤81中，结果交换器保存当前应用运行的环境。接着在步骤82中，禁用(即，屏蔽)中断(IRQ)以避免在写入数据时遭到中断的打断。接着在步骤83中，查找空的chunck或预留的chunck，例如通过上面所描述的三个标志位字段来查找，如果找到空的chunck，则在步骤84中，将数据写入到该空的chunck中，如将本发明中找到的配置文件列表存储到该空的chunck中。如果没有找到空的chunck，则在步骤85中，将多个chunck中最老的一个chunck擦除以便在步骤84中将新的数据写入到该chunck中，该最老的一个chunck可以通过上面提到的短时间戳标志位(TS)来确定。在写入数据后，在步骤86中，CPU恢复保存的运行环境并且重新打开前面禁用的中断(IRQ)，以便进程执行后续的操作，例如由Launcher模块查询chunck的标识字段，将已准备好的数据读出，并在适当的时候清空缓冲区。

图9是示意性示出根据本发明一个实施方式的用于自动地查找系统中应用的配置文件的方法的流程图。如同根据图1a和图1b所描述的，根据本发明的最基本的实施例，在步骤901处，获取关注的应用的进程标识符。在步骤902处，将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较。接着在步骤903处，当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

可以进一步获取与应用通信的进程的进程标识符，即通信进程标识符。通过捕获进程间的关联关系，例如共享同一文件、存在管道、通过消息交换数据、存在调用关系，可以确认两个进程之间存在通信。特别地，在Windows操作系统中，可以通过COM管理器来获取所述通信进程标识符。将所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较，如果所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则所述配置文件也是所关注的应用的配置文件。

图10是示意性示出根据本发明一个实施方式的用于自动地查找系统中应用的配置文件的设备的框图。如图中所示，所述设备分别包括获取装置1001、比较装置1002和确定装置1003。在该设备中，获得装置1001用于获取关注的应用的进程标识符，比较装置1002用于将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较，而确定装置1003用于当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

本发明的实施方式可以通过硬件、软件、固件或者其结合来实现。本领域技术人员应该认识到，也可以在供任何合适数据处理系统使用的信号承载介质上所设置的计算机程序产品中体现本发明。这种信号承载介质可以是传输介质或用于机器可读信息的可记录介质，包括磁介质、光介质或其他合适介质。可记录介质的示例包括：硬盘驱动器中的磁盘或软盘、用于光驱的光盘、磁带，以及本领域技术人员所能想到的其他介质。本领域技术人员应该认识到，具有合适编程装置的任何通信终端都将能够执行如程序产品中体现的本发明方法的步骤。

应当注意，为了使本发明更容易理解，上面的描述省略了对于本领域的技术人员来说是公知的、并且对于本发明的实现可能是必需的更具体的一些技术细节。

提供本发明的说明书的目的是为了说明和描述，而不是用来穷举或将本发明限制为所公开的形式。对本领域的普通技术人员而言，许多修改和变更都是显而易见的。

因此，选择并描述实施方式是为了更好地解释本发明的原理及其实际应用，并使本领域普通技术人员明白，在不脱离本发明实质的前提下，所有修改和变更均落入由权利要求所限定的本发明的保护范围之内。

Claims

1.一种用于查找系统中应用的配置文件的方法，所述方法包括以下步骤：

获取关注的应用的进程标识符；

将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；

当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

2.根据权利要求1所述的方法，进一步包括：

获取与关注的应用通信的进程的通信进程标识符；

将所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；

当所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

3.根据权利要求1或2所述的方法，其中对所述配置文件进行操作包括对配置文件执行打开操作、读操作或写操作之一。

4.根据权利要求2所述的方法，其中设置通信距离门限，所述获取与关注的应用通信的进程的通信进程标识符的步骤包括：

获取与关注的应用通信、且通信距离小于所述通信距离门限的进程的进程标识符作为所述通信进程标识符。

5.根据权利要求2或4所述的方法，其中所述系统是Windows操作系统，所述获取与关注的应用通信的进程的通信进程标识符的步骤包括：

利用COM管理器来获取与所关注的应用相关的COM实例的进程标识符作为所述通信进程标识符。

6.根据权利要求1所述的方法，其中还包括将所关注的应用的配置文件与系统中被执行写操作的配置文件进行比较，以确定所关注的应用的配置文件中发生改变的配置文件。

7.根据权利要求6所述的方法，其中在确定发生改变的配置文件后，对该发生改变的配置文件进行版本控制操作。

8.根据权利要求6所述的方法，其中将所关注的应用的配置文件从系统的内核态传递到系统的用户态以便进行比较。

9.根据权利要求8所述的方法，其中还包括在系统的内核态和用户态为关注的多个应用分别分配相对应的存储配置文件的缓冲区。

10.根据权利要求8所述的方法，其中还包括在系统的内核态中针对运行多个应用的每个中央处理器来分配存储相关的配置文件的缓冲区，而在系统的用户态中为关注的每个应用分配相对应的缓冲区。

11.一种用于查找系统中应用的配置文件的设备，所述设备包括：

获取装置，用于获取关注的应用的进程标识符；

比较装置，用于将所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较；

确定装置，用于当所获取的进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件。

12.根据权利要求11所述的设备，进一步包括：

获取与关注的应用通信的进程的通信进程标识符的装置；

将所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符进行比较的装置；

当所获取的通信进程标识符与系统中对配置文件进行操作的进程的进程标识符相同时，则确定所述配置文件是所关注的应用的配置文件的装置。