CN113468112B - 文件管理方法、装置、存储介质及计算机设备 - Google Patents

Abstract

本申请实施例公开了一种文件管理方法、装置、存储介质及计算机设备。该方法包括：通过用户进程获取文件访问请求，通过分支确定模块确定文件访问请求所需访问的待访问文件的加解密属性，并在加解密属性表示待访问文件无需加解密时，确定待访问文件的相对路径信息，基于相对路径信息，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，并响应文件访问请求，在加解密属性表示待访问文件需要加解密时，确定待访问文件的全路径信息，基于全路径信息，通过虚拟文件系统、用户态文件系统的内核态模块、用户态文件系统的用户态模块、原生文件系统，对待访问文件进行管理，并响应文件访问请求。本申请实施例提高了操作系统的文件系统性能。

Description

文件管理方法、装置、存储介质及计算机设备

技术领域

本申请涉及信息处理技术领域，具体涉及一种文件管理方法、装置、计算机可读存储介质及计算机设备。

背景技术

近年来，随着个人计算机、办公自动化的普及，保护敏感文件不被泄漏成为人们关注的热点问题。系统入侵者除了直接窃取存储信息，还可以通过网络攻击来窃夺文件数据；而且，由于共享的需求，敏感数据会有多人访问，这也增大了数据泄漏的可能性。

对数据或文件进行加密已经成为一种公认的比较成功的保护方法，因此透明加解密技术应运而生。所谓透明加解密，是指在不改变用户操作习惯的情况下完成文件的加密和解密过程。

目前对于操作系统，如Linux操作系统来说，对文件进行加解密也使用了透明加解密技术。Linux系统中常用的透明加解密技术为用户态文件系统，或者也称为FUSE文件系统（Filesystem in Userspace）、用户空间文件系统，其属于一种透明加解密文件系统。

FUSE文件系统最大缺点就是性能问题。在进行文件访问时，使用FUSE文件系统访问文件的速度较低，使得Linux操作系统的文件系统性能较低，影响了用户体验。

发明内容

本申请实施例提供一种文件管理方法、装置、计算机可读存储介质及计算机设备，可以提高文件系统的访问速率，提高文件的访问性能。

本申请实施例提供了一种文件管理方法，应用于计算机设备中，所述计算机设备包括用户空间和内核空间，所述计算机设备的文件系统包括虚拟文件系统、用户态文件系统和原生文件系统，所述用户态文件系统包括内核态模块和用户态模块，所述虚拟文件系统、所述内核态模块、所述原生文件系统运行于所述内核空间中，所述用户进程、所述用户态模块、分支确定模块运行于所述用户空间中，文件管理方法包括：

通过用户进程获取文件访问请求；

通过所述分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

当所述加解密属性表示所述待访问文件无需加解密时，确定所述待访问文件的相对路径信息；并基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

当所述加解密属性表示所述待访问文件需要加解密时，确定所述待访问文件的全路径信息；并基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

本申请实施例还提供一种文件管理装置，应用于所述计算机设备中，所述计算机设备包括用户空间和内核空间，所述计算机设备的文件系统包括虚拟文件系统、用户态文件系统和原生文件系统，所述用户态文件系统包括内核态模块和用户态模块，所述虚拟文件系统、所述内核态模块、所述原生文件系统运行于所述内核空间中，所述用户进程、所述用户态模块、分支确定模块运行于所述用户空间中，包括：

请求获取模块，用于通过用户进程获取文件访问请求；

加解密确定模块，用于通过分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

第一路径确定模块，用于当所述加解密属性表示所述待访问文件无需加解密时，确定所述待访问文件的相对路径信息；

第一管理模块，用于基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

第二路径确定模块，用于当所述加解密属性表示所述待访问文件需要加解密时，确定所述待访问文件的全路径信息；

第二管理模块，用于基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于处理器进行加载，以执行如上任一实施例所述的文件管理方法中的步骤。

本申请实施例还提供一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器通过调用所述存储器中存储的所述计算机程序，执行如上任一实施例所述的文件管理方法中的步骤。

本申请实施例提供的文件管理方法、装置、计算机可读存储介质及计算机设备，通过增加分支确定模块，以在用户进程获取文件访问请求后，通过分支确定模块确定文件访问请求所需访问的待访问文件的加解密属性，并在加解密属性表示待访问文件无需加解密时，确定待访问文件的相对路径信息，基于相对路径信息，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，并响应文件访问请求，同时在加解密属性表示待访问文件需要加解密时，确定待访问文件的全路径信息，基于全路径信息，通过虚拟文件系统、用户态文件系统的内核态模块、用户态文件系统的用户态模块、原生文件系统，对待访问文件进行管理，并响应文件访问请求。由于挂载了用户态文件系统之后，所有的文件访问请求都需要经过用户态文件系统，本申请利用分支确定模块来确定待访问文件的加解密属性，并在加解密属性表示待访问文件无需加解密时，确定待访问文件的相对路径信息，实现了无需加解密的待访问文件对应的文件访问请求直接通过虚拟文件系统来访问原生文件系统，从而绕开了用户态文件系统，提高了操作系统的文件系统性能；而在加解密属性表示待访问文件需要加解密时，通过虚拟文件系统、用户态文件系统、原生文件系统，实现对待访问文件的管理，保持了文件系统的原有功能。即本申请实施例在保持文件系统的原有功能的基础上，提高了操作系统的文件系统性能。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中的文件管理方法的流程示意图。

图2为本申请实施例提供的文件管理方法的流程示意图。

图3为本申请实施例提供的文件管理方法的又一流程示意图。

图4为本申请实施例提供的文件管理方法的另一示意图。

图5为本申请实施例提供的分支确定模块的处理流程示意图。

图6为本申请实施例提供的文件管理装置的结构示意图。

图7为本申请实施例提供的文件管理装置的另一结构示意图。

图8为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供一种文件管理方法、装置、计算机可读存储介质及计算机设备。具体地，本申请实施例的文件管理方法可以由计算机设备执行，其中，该计算机设备可以为终端或者服务器等安装有操作系统的设备。该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、个人计算机（PC，Personal Computer）等终端设备。服务器可以是独立的物理服务器，还可以是提供云服务、云数据库等基础云计算服务的云服务器等。

其中，计算机设备中安装有操作系统，如Linux操作系统、unix操作系统等，本申请中以计算机设备中安装有Linux操作系统为例进行说明。

在Linux操作系统中，把内存划分为两部分，包括用户空间和内核空间，Linux操作系统和驱动程序运行在内核空间，应用程序运行在用户空间。内核空间和用户空间之间相互隔离。在内核空间中，可以执行任意命令，可以调用系统的一切资源；在用户空间中，只能执行简单的运算，不能直接调用系统资源。用户空间需要通过系统接口，才能向内核空间发出对应请求/指令。

如图1所示，在Linux操作系统中，包括用户空间和内核空间。图1中的位于用户空间和内核空间之间的无箭头的实线表示用户空间和内核空间的分隔线。应用程序所对应的用户进程运行于用户空间中。在内核空间中，包括用于操作文件的文件系统。文件系统包括虚拟文件系统（VFS，Virtual Filesystem Switch）、用户态文件系统（FUSE文件系统）和原生文件系统。如图1所示，用户态文件系统包括运行于内核空间的内核态FUSE模块（本文中也称为内核态模块）和运行于用户空间的用户态FUSE模块（本文中也称为用户态模块），其中，用户态FUSE模块提供加解密业务逻辑，实现对待访问文件的加解密功能。

其中，虚拟文件系统用于给用户空间的程序提供系统接口，同时屏蔽底层各种文件系统（包括各种原生文件系统等，如ext2、ext3、ext4、rootfs、proc）的差异，IO请求（如文件访问请求）都需要经过虚拟文件系统，需转换成虚拟文件系统的结构才能访问其他文件系统（包括原生文件系统等），所有其他文件系统（包括原生文件系统等）都需要先转换成虚拟文件系统的结构才能为用户所调用。用户态文件系统用于对IO请求进行进一步的处理，如实现对IO请求所需访问的待访问文件进行加密/解密等。IO请求访问用户态文件系统后，再调用原生文件系统，利用原生文件系统来获取待访问文件/对待访问文件进行操作等。

请继续参看图1，图1中的实线实心箭头是用户进程的IO请求的请求方向，实线空心箭头是用户进程的IO请求响应完成后的返回方向。可以看到，用户进程的IO请求先访问内核空间的虚拟文件系统，再通过虚拟文件系统访问内核态FUSE模块，内核态FUSE模块接着访问用户空间的用户态FUSE模块（用户态FUSE模块会对IO请求进行处理，在一些实施例中也有可能不进行处理，下文中将会详细说明），在访问用户态FUSE模块之后，将IO请求发送至原生文件系统，以通过原生文件系统对IO请求进行管理。对所述IO请求响应完成后，原生文件系统将响应IO请求的响应结果通过用户空间的用户态FUSE模块返回（用户态FUSE模块会对IO请求进行处理，在一些实施例中也有可能不进行处理，下文中将会详细说明），再返回至内核空间的内核态FUSE模块，通过内核态FUSE模块返回至虚拟文件系统，虚拟文件系统将响应结果返回至用户空间的用户进程。

需要注意的是，IO请求从用户空间切换至内核空间，或者从内核空间切换至用户空间时，会发生上下文（context）转换，而上下文转换往往需要消耗大量系统资源（CPU，内存等资源）。从图1中可以看出，一个响应完成的IO请求需要六次上下文切换（俗称的三进三出），开销巨大。此外，内核空间的内核态FUSE模块需要维护一个IO请求的队列。其中，当需要读写大文件时，会有大量请求，例如，以4K的IO请求去读一个100M的大文件，就会有25600次请求。内核态FUSE模块维护大规模的IO请求的队列，也会带来巨大的系统资源。

然而针对我们的使用场景，在实际使用场景中，需要加解密处理的文件只占总文件的很少比例（例如低于5%）。大量二进制文件、配置文件、系统文件、临时文件和不关心的其他文件无需加解密。而在上述文件系统中，这些无需加解密的文件仍然会经过用户态文件系统，依旧会经过六次上下文切换，造成文件系统的访问效率较低，影响了文件系统的性能。

本申请实施例针对计算机设备的文件系统的访问效率降低，从而影响文件系统的性能的技术问题，提出了一种文件管理方法、装置、计算机可读存储介质及计算机设备，以解决该技术问题。

以下将分别对本申请实施例提供的一种文件管理方法、装置、计算机可读存储介质及计算机设备进行详细说明。需说明的是，以下实施例的序号不作为对实施例优选顺序的限定。

以下所述的文件管理方法、文件管理装置应用于计算机设备中，该计算机设备中的内存包括用户空间和内核空间，该计算机设备的文件系统包括虚拟文件系统、用户态文件系统和原生文件系统。所述用户态文件系统包括内核态模块和用户态模块。虚拟文件系统、内核态模块、原生文件系统运行于内核空间中，用户进程、用户态模块、分支确定模块运行于用户空间中，以下将不再赘述。需要说明的是，以下实施例中的计算机设备与图1所示的计算机设备的不同之处在于：在用户空间中，增加了分支确定模块。其中，分支确定模块的作用下文中将会详细描述。

图2是本申请实施例提供的文件管理方法的流程示意图，该文件管理方法包括如下步骤。

101，通过用户进程获取文件访问请求。

在Linux操作系统中，将一切资源都简化为文件，将这些资源的操作简化为对文件的操作。即在Linux操作系统中，一切皆文件。例如，目录是文件、串口设备是文件，内存是文件，USB是文件，进程信息是文件，网卡是文件，建立的每个网络通讯都是文件，蓝牙设备也是文件等。因此，文件访问请求对应的是对Linux操作系统中的任一文件的访问请求。例如，可以是对目录文件进行访问的访问请求、可以是对串口设备对应的设备文件进行访问的访问请求、可以是对蓝牙设备对应的设备文件进行访问的访问请求等。

其中，用户进程指的是运行于用户空间的应用程序的进程。该应用程序可以是任一可安装且可运行在Linux操作系统中的用户空间的应用程序。应用程序运行过程中，会涉及到文件访问，通过用户进程获取该文件访问对应的文件访问请求。文件访问请求中包括待访问文件的文件路径和/或用户进程信息。其中，用户进程信息用于确定文件访问请求来自于哪个用户进程。用户进程信息可包括用户进程标识和/或用户进程名称等。

所述文件访问请求包括文件打开请求、文件读写请求（包括文件读请求、文件写请求）、文件关闭请求等。

102，通过分支确定模块确定文件访问请求所需访问的待访问文件的加解密属性。

其中，分支确定模块是计算机设备中新增的模块。分支确定模块运行于用户空间中，分支确定模块在文件访问请求进入至内核空间之前运行。分支确定模块的作用如步骤102至步骤104所述，即步骤102至步骤104所实现的功能由分支确定模块来完成。

在一实施例中，步骤102，包括：通过分支确定模块获取文件访问请求，并确定文件访问请求所需访问的待访问文件的加解密属性。

在一实施例中，通过分支确定模块获取文件访问请求的步骤，包括：通过分支确定模块拦截文件访问请求，以获取该文件访问请求。具体地，利用钩子技术来拦截文件访问请求。

在一实施例中，确定文件访问请求所需访问的待访问文件的加解密属性的步骤，包括：根据文件路径和/或用户进程信息确定文件访问请求所需访问的待访问文件的加解密属性。

进一步地，获取路径黑名单、进程黑名单、路径进程组合黑名单。路径黑名单、进程黑名单、路径进程组合黑名单预先保存，如保存在配置文件中。

路径黑名单中配置我们完全不关心的文件路径，当截取到文件访问请求时，获取文件访问请求所对应的文件路径，并将获取的文件路径与路径黑名单中的路径进行比对。

进程黑名单中配置文件系统中我们完全不关心的进程，当截取到文件访问请求时，获取文件访问请求所对应的用户进程信息，并将所获取的用户进程信息与进程黑名单中的进程进行比对。

路径进程组合黑名单中配置我们不关心的（路径，进程）二元组，当截取到文件访问请求时，获取文件访问请求所对应的文件路径和用户进程信息，并将所获取的文件路径和用户进程信息所对应的二元组与路径进程组合黑名单中的二元组进行比对。

上述根据文件路径和/或用户进程信息确定文件访问请求所需访问的待访问文件的加解密属性的步骤，包括：

当文件路径属于路径黑名单中的路径时，确定文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者

当用户进程信息属于进程黑名单中的进程信息时，确定文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者

当文件路径和用户进程信息属于路径进程组合黑名单中的一条记录信息时，确定文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定文件访问请求所需访问的待访问文件的加解密属性为需要加解密。

通过上述三种不同的方式来确定文件访问请求所需访问的待访问文件的加解密属性。需要注意的是，上述三种方式只是举例说明，还可以采用其他方式来确定文件访问请求所需访问的待访问文件的加解密属性。

103，当加解密属性表示待访问文件无需加解密时，确定待访问文件的相对路径信息；并基于相对路径信息，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，以响应文件访问请求。

其中，待访问文件的相对路径信息包括用户态文件系统的挂载点的基址文件描述符和待访问文件的基于所述基址文件描述符的相对路径。其中，基址文件描述符指的是用户态文件系统的挂载点在未挂载之前对应的文件描述符。

文件描述符是Linux操作系统的一个变量，通常通过open函数返回，其在形式上是一个非负整数。实际上文件描述符是一个索引值，指向内核空间为每一个用户进程所维护的该用户进程打开文件的记录表。当应用程序打开一个现有文件或者创建一个新文件时，内核空间向用户进程返回一个文件描述符。

例如，int fd = open(“文件路径”, flag); 在调用open函数后，返回值对应的fd（file descriptor），就是一个文件描述符。fd指向的文件就是调用open函数时对应的“文件路径”。

基址文件描述符指的是用户态文件系统在未挂载之前的挂载点的文件描述符。假设Linux操作系统下的用户态文件系统的挂载点路径是/home/andin。那么在挂载点未挂载之前，基址文件描述符就是int fd = open(“/home/andin”, flag); 函数的返回值，即这时返回的fd就是基址文件描述符。

基于用户态文件系统的挂载点的基址文件描述符和待访问文件的基于所述基址文件描述符的相对路径，通过第一系统接口来操作待访问文件。

例如，假设用户态文件系统挂载点为/home/andin目录，文件访问请求所需访问的待访问文件的文件路径为/home/andin/test.doc（该文件路径为绝对路径），则基于基址文件描述符的相对路径为test.doc。若加解密属性表示待访问文件无需加解密，调用第一系统接口所对应的openat函数，利用openat（“/home/andin”,“test.doc”，……）来操作待访问文件。其中，省略号为其他参数，“/home/andin”在执行对应函数后，返回的即为用户态文件系统的挂载点的基址文件描述符。

在执行openat函数的过程中，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，以响应文件访问请求。其中，由于基址文件描述符是用户态文件系统的挂载点在未挂载之前的文件描述符，因此，基址文件描述符指向的路径仍然是原生文件系统的路径，如此，实现了无需加解密的待访问文件的文件访问请求直接通过虚拟文件系统来访问原生文件系统，从而绕开了用户态文件系统，提供了操作系统的文件系统性能。

如图3所示，为本申请实施例提供的文件管理方法的流程示意图。其中，图3中的实心箭头（包括实线实心箭头和虚线实心箭头）皆指的是用户进程对应的文件访问请求的请求方向，空心箭头（包括实线空心箭头和虚线空心箭头）皆指的是用户进程对应的文件访问请求响应完成后的返回方向。其中，虚线箭头（包括虚线实心箭头和虚线空心箭头）对应的是文件访问请求的待访问文件在无需加解密的情况下，所对应的相应处理流程；实线箭头（包括实线实心箭头和实线空心箭头）对应的是文件访问请求的待访问文件在需要加解密的情况下，所对应的相应处理流程。

在图3中，文件访问请求在通过分支确定模块处理后，存在两个不同的分支，该两个不同的分支分别对应文件访问请求的待访问文件无需加解密的情况下所对应的请求流程（虚线实心箭头）和待访问文件需要加解密的情况下所对应的请求流程（实线实心箭头）。如图3所示，在待访问文件无需加解密时，文件访问请求在访问虚拟文件系统之后，直接访问原生文件系统，绕开了用户态文件系统。

在响应完成后，无需加解密的情况下所对应的返回流程对应的是虚线空心箭头，通过图3可知，在无需加解密的情况下，响应文件访问请求的响应结果通过原生文件系统、虚拟文件系统，直接返回至用户进程，在返回响应结果时，也绕开了用户态文件系统。

如此，一个响应完成的文件访问请求只有两次的上下文切换（一进一出），并且不会经过内核FUSE模块，无需进入内核FUSE模块中的队列，从而大幅度提高了文件系统的性能。

104，当加解密属性表示待访问文件需要加解密时，确定待访问文件的全路径信息；并基于全路径信息，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行管理，以响应文件访问请求。

其中，全路径信息指的是待访问文件的完整路径信息。

文件访问请求中包括文件路径，由于文件访问请求是用户进程对应的应用程序发出的，因此，所对应的文件路径有可能是相对路径，也有可能是绝对路径。对应地，确定待访问文件的全路径信息的步骤，包括：检测待访问文件的文件路径是否为绝对路径；若是，则直接将待访问文件的文件路径作为待访问文件的全路径信息；若待访问文件的文件路径为相对路径，则获取用户进程的基础路径，根据基础路径和相对路径确定待访问文件的全路径信息。

其中，基础路径指的是用户进程的默认的路径，所有相对路径都是基于该基础路径的，因此，可通过用户进程的基础路径和相对路径来确定待访问文件的绝对路径，该将绝对路径作为待访问文件的全路径信息。

确定了待访问文件的全路径信息后，基于全路径信息，通过第二系统接口来操作待访问文件。

例如，假设用户态文件系统挂载点为/home/andin目录，文件访问请求所需访问的待访问文件的文件路径为/home/andin/test.doc，若加解密属性表示待访问文件无需加解密，调用第二系统接口所对应的open函数，利用open(“/home/andin/test.doc”，……)来操作待访问文件。其中，省略号为其他参数，“/home/andin/test.doc”为待访问文件的全路径信息。

在执行open函数的过程中，通过虚拟文件系统、内核态FUSE模块、用户态FUSE模块、原生文件系统，对待访问文件进行管理，以响应文件访问请求。其中，利用用户态FUSE模块来对待访问文件进行加解密处理等，以实现对待访问文件的透明加解密功能。即当加解密属性表示待访问文件需要加解密时，通过虚拟文件系统、用户态文件系统、原生文件系统，实现对待访问文件的管理，保持了文件系统的原有功能。

如图3所示，在待访问文件需要加解密时，所对应的请求流程为实线实心箭头所对应的流程，所对应的返回流程为实线空心箭头的所对应的流程。在请求流程中，文件访问请求在访问虚拟文件系统之后，访问用户态文件系统的内核态FUSE模块，接着访问用户态文件系统的用户态FUSE模块（在用户态FUSE模块可对待访问文件进行一些处理，根据文件访问请求的不同，也可能会不进行处理），用户态FUSE模块访问完成后，再访问原生文件系统。在返回流程中，按照原路径返回。其中，用户态文件系统的内核态FUSE模块与用户态FUSE模块之间的通信通过管道技术来实现，在此不进行详细说明。

该实施例在用户空间中新增了分支确定模块，利用分支确定模块来确定待访问文件的加解密属性，并在加解密属性表示待访问文件无需加解密时，确定待访问文件的相对路径信息，实现了无需加解密的待访问文件对应的文件访问请求直接通过虚拟文件系统来访问原生文件系统，从而绕开了用户态文件系统，提高了操作系统的文件系统性能；而在加解密属性表示待访问文件需要加解密时，通过虚拟文件系统、用户态文件系统、原生文件系统，实现对待访问文件的管理，保持了文件系统的原有功能。即本申请实施例在保持文件系统的原有功能的基础上，提高了操作系统的文件系统性能。

图4是本申请实施例提供的文件管理方法的另一流程示意图。如图4所示，该文件管理方法包括如下步骤。

201，通过用户进程获取文件访问请求，该文件访问请求包括文件访问请求所需访问的待访问文件的文件路径和/或用户进程信息。

202，通过分支确定模块拦截文件访问请求。

通过分支确定模块，在文件访问请求进入内核空间之前，利用钩子技术来拦截文件访问请求。

203，根据文件路径和/或用户进程信息确定文件访问请求所需访问的待访问文件的加解密属性。

204，当加解密属性表示待访问文件无需加解密时，获取用户态文件系统的挂载点的基址文件描述符，该基址文件描述符指的是挂载点在未挂载之前对应的文件描述符。

在一实施例中，在上述获取用户态文件系统的挂载点的基址文件描述符的步骤之前，所述文件管理方法，还包括：在计算机设备开机时，创建预设进程；在用户态文件系统启动之前，利用预设进程来获取用户态文件系统的挂载点的基址文件描述符；保存基址文件描述符。

由于基址文件描述符是挂载点在未挂载之前对应的文件描述符，而在用户态文件系统启动之后，所获取的文件描述符必定是挂载点挂载之后的文件描述符。因此，在计算机设备开机时，创建一个预设进程，在用户态文件系统启动之前，利用预设进程来获取用户态文件系统的挂载点的基址文件描述符，并将基址文件描述符保存。在用户态文件系统启动之前，所获取的基址文件描述符一定是用户态文件系统未挂载之前，挂载点所对应的文件描述符。利用预设进程在用户态文件系统启动之前，获取并保存基址文件描述符，使得所获取的基址文件描述符准确无误。由于在用户态文件系统启动之前，所获取的基址文件描述符，此时，用户态文件系统还没有挂载，所以所获取的基址文件描述符指向的路径仍是原生文件系统的。

对应地，上述获取用户态文件系统的挂载点的基址文件描述符的步骤，包括：向预设进程发送描述符获取请求，该描述符获取请求用于请求用户态文件系统的基址文件描述符；并接收预设进程返回的基址文件描述符。如此，确保所获取的用户态文件系统的基址文件描述符是准确无误的，所获取的基址文件描述符指向的路径是原生文件系统的路径。

如图5所述，为分支确定模块的处理流程示意图。分支确定模块首先拦截文件访问请求，并确定文件访问请求对应的待访问文件的加解密属性。当加解密属性表示待访问文件无需加解密时，向预设进程发送描述符获取请求，预设进程返回基址文件描述符。

205，确定待访问文件的相对路径。

根据待访问文件的绝对路径和基址文件描述符确定待访问文件的相对路径。具体地，以基址文件描述符所对应的挂载点为基址，根据待访问文件的绝对路径和基址来确定待访问文件的相对路径。

例如，假设用户态文件系统挂载点为/home/andin目录，即基址为/home/andin目录，文件访问请求所需访问的待访问文件的文件路径为/home/andin/test.doc（该文件路径为绝对路径），则根据待访问文件的绝对路径和基址来确定待访问文件的相对路径为test.doc。

206，将基址文件描述符和相对路径确定为待访问文件的相对路径信息。

本申请实施例中的待访问文件的相对路径信息包括基址文件描述符和所确定的相对路径。

207，基于相对路径信息，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，以响应文件访问请求。

假设文件访问请求所需访问的待访问文件的文件路径为/home/andin/test.doc，挂载点为/home/andin，用户态文件系统的根目录也是/home/andin，把用户态文件系统挂载在对应的挂载点。

若加解密属性表示待访问文件无需加解密，调用第一系统接口所对应的openat函数，利用openat（“/home/andin”,“test.doc”，……）来操作待访问文件。其中，省略号为其他参数，“/home/andin”在执行对应函数后，返回的即为用户态文件系统的挂载点的基址文件描述符。或者第一系统接口所对应的openat函数，可以表示为openat(基址文件描述符，“相对路径”，……)。

具体地，如图5所示。在加解密属性表示待访问文件无需加解密时，基于相对路径信息（基址文件描述符和待访问文件的相对路径）来操作文件。如打开待访问文件等。

由于在用户态文件系统挂载前获取了挂载点的基址文件描述符，本例中就是“/home/andin”的文件描述符，获取基址文件描述符时用户态文件系统还没有被挂载，所以“/home/andin”的文件描述符指向的路径还是原生文件系统的路径。

当文件访问请求为文件打开请求时，该文件打开文件用于打开待访问文件，Linux操作系统根据文件访问请求，沿着对应的文件路径搜寻待访问文件的真实节点。

具体地，搜寻的步骤如下：

第一步，先搜寻用户态文件系统的基址文件描述符指向的路径，即/home/andin，因为是在挂载前获取的基址文件描述符，所以搜寻到的/home/andin路径依旧是原生文件系统的路径；

第二步，搜寻/home/andin/c.txt，找到了c.txt，使用原生文件系统的open函数打开c.txt。

如此，实现了无需加解密的待访问文件的文件访问请求直接通过虚拟文件系统来访问原生文件系统，从而绕开了用户态文件系统，减少了上下文切换的次数，并且文件访问请求不会经过内核FUSE模块，无需进入内核FUSE模块中的队列，从而提高了操作系统的文件系统性能。

通过本申请实施例的方式，实现了针对同一路径的情况下，在文件访问请求进入虚拟文件系统后，可选择性的使用原生文件系统或者用户态文件系统。

208，当加解密属性表示待访问文件需要加解密时，确定待访问文件的全路径信息。

209，基于全路径信息，调用第二系统接口，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行管理，以响应文件访问请求。

确定了待访问文件的全路径信息后，基于全路径信息，通过第二系统接口来操作待访问文件。

同样，假设用户态文件系统挂载点为/home/andin目录，文件访问请求所需访问的待访问文件的文件路径为/home/andin/test.doc，若加解密属性表示待访问文件无需加解密，调用第二系统接口所对应的open函数，利用open(“/home/andin/test.doc”，……)来操作待访问文件。其中，省略号为其他参数，“/home/andin/test.doc”为待访问文件的全路径信息。或者第二系统接口所对应的open函数，可以表示为open(“全路径”，……)。

如图5所示，当待访问文件的加解密属性表示待访问文件无需加解密时，基于全路径信息来操作文件。如打开待访问文件等。

当文件访问请求为文件打开请求时，该文件打开文件用于打开待访问文件，Linux操作系统根据文件访问请求，沿着对应的文件路径搜寻待访问文件的真实节点。

具体地，搜寻的步骤如下：

第一步，搜寻/，即Linux操作系统的根路径，/路径是Linux操作系统的原生文件系统的路径；

第二步，搜寻/home，/home也是Linux操作系统的原生文件系统的路径；

第三步，搜寻/home/andin，/home/andin是对应的挂载点，当Linux发现一个路径是挂载点后，就会查找挂载在该挂载点上的文件系统，然后发现该文件系统是用户态文件系统（FUSE文件系统），此时搜寻路径就会从原生文件系统的/home/andin切换到FUSE文件系统的根目录；而对应的挂载参数中，FUSE文件系统根目录恰巧也是/home/andin，所以此时搜寻到的路径还是/home/andin，只不过此时的文件系统已经切换到了FUSE文件系统，所有的文件操作也会使用FUSE文件系统的操作函数。

第四步，搜寻/home/andin/c.txt，找到了c.txt，使用FUSE文件系统的open函数打开c.txt。

正常情况下，访问挂载点后的文件，一定会使用挂载的文件系统，如本申请中的FUSE文件系统。

该实施例中未详细描述的步骤请参看上文中对应步骤的描述，在此不再赘述。

由于挂载了用户态文件系统之后，所有的文件访问请求都需要经过用户态文件系统，该实施例在文件访问请求进入内核空间之前，利用钩子技术对文件访问请求进行拦截，并在确定文件访问请求对应的待访问文件无需加解密时，获取基址文件描述符，由于基址文件描述符是在用户态文件系统的挂载点未挂载之前对应的文件描述符，因此，该基址文件描述符指向的路径仍然是原生文件系统的路径，如此实现了无需加解密的待访问文件对应的文件访问请求直接通过虚拟文件系统来访问原生文件系统，而绕开了用户态文件系统，减少了上下文切换的次数，且文件访问请求也无需进入内核FUSE模块中的队列，大幅提高了操作系统的文件系统性能。在需要加解密的待访问文件需要加解密时，通过虚拟文件系统、用户态文件系统、原生文件系统，实现对待访问文件的管理，保持了文件系统的原有功能。通过本申请实施例的方式，实现了针对同一路径的情况下，在文件访问请求进入虚拟文件系统之后，可以选择性的使用原生文件系统或者用户态文件系统。

上述方法实施例中，文件访问请求包括文件打开请求，当待访问文件的加解密属性表示待访问文件无需加解密时，对应地，上述基于相对路径信息，通过虚拟文件系统、原生文件系统，对待访问文件进行管理，并响应文件访问请求的步骤，包括：基于相对路径信息，通过虚拟文件系统、原生文件系统，确定待访问文件的文件描述符，并打开待访问文件，以响应文件打开请求。在响应完成后的返回流程中，将待访问文件的文件描述符通过原生文件系统、虚拟文件系统返回至用户进程。

表1是本申请实施例中未使用分支确定模块和使用了分支确定模块之后的文件系统的测试结果示意表。其中，测试的文件访问请求为文件打开请求，分支确定模块使用钩子技术来拦截文件打开请求，确定该文件打开请求的加解密属性为无需加解密。该文件打开请求请求打开100M的docx格式的待访问文件，测试时间均为多次从双击待访问文件的图标到显示待访问文件的内容所对应的测试时间的均值。

表1 未使用分支确定模块和使用分支确定模块之后的文件系统的测试结果示意表

测试环境	未使用分支确定模块	使用分支确定模块
			龙芯测试机+银河麒麟V10系统	45秒	24秒
飞腾测试机+银河麒麟V10系统	21秒	10秒
			X86平台+中科方德系统	9秒	3秒

从表1可看出，使用了本申请实施例中的分支确定模块之后，文件系统的效率提升了不止一倍，提升效果明显。

在一实施例中，文件访问请求还包括文件读写请求（包括文件读请求和文件写请求），当待访问文件的加解密属性表示待访问文件无需加解密时，对应的，文件管理方法，还包括：通过用户进程获取待访问文件的文件读写请求；根据待访问文件的文件描述符，通过虚拟文件系统、原生文件系统，对待访问文件进行读写，以响应文件读写请求。在响应文件读写请求完成后，将响应文件读写请求的响应结果通过原生文件系统、虚拟文件系统，返回至用户进程。

在一实施例中，文件访问请求还包括文件关闭请求，当待访问文件的加解密属性表示待访问文件无需加解密时，对应的，文件管理方法，还包括：通过用户进程获取待访问文件的文件关闭请求；根据待访问文件的文件描述符，通过虚拟文件系统、原生文件系统，对待访问文件进行关闭并使得待访问文件的文件描述符失效，以响应文件关闭请求。在响应文件关闭请求完成后，将响应文件关闭请求的响应结果通过原生文件系统、虚拟文件系统，返回至用户进程。

在一实施例中，文件访问请求包括文件打开请求，当待访问文件的加解密属性表示待访问文件需要加解密时，对应地，上述基于全路径信息，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行管理，并响应文件访问请求的步骤，包括：基于全路径信息，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，确定待访问文件的文件描述符，并打开待访问文件，以响应文件打开请求。在响应完成后的返回流程中，待访问文件的文件描述符通过原生文件系统、用户态模块、内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求还包括文件读请求，当待访问文件的加解密属性表示待访问文件需要加解密时，对应的，文件管理方法，还包括：通过用户进程获取待访问文件的文件读请求；根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行读取，以响应文件读请求。在响应文件读请求完成后，将响应文件读请求的响应结果（读取内容）通过原生文件系统发送至用户态模块，在用户态模块中，对响应结果利用算法库进行解密，以得到解密后的响应结果，并将解密后的响应结果通过内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求还包括文件写请求，当待访问文件的加解密属性表示待访问文件需要加解密时，对应的，文件管理方法，还包括：通过用户进程获取待访问文件的文件写请求；根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块将文件写请求发送至用户态模块，用户态模块将文件写请求所对应的写入内容进行加密处理，以得到加密处理后的写入内容，将加密处理后的写入内容通过原生文件系统写入至对应的磁盘，以响应文件写请求。在响应文件读请求完成后，将响应文件读请求的响应结果通过原生文件系统、用户态模块、内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求还包括文件关闭请求，当待访问文件的加解密属性表示待访问文件需要加解密时，对应的，文件管理方法，还包括：通过用户进程获取待访问文件的文件关闭请求；根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行关闭并使得待访问文件的文件描述符失效，以响应文件关闭请求。在响应文件关闭请求完成后，将响应文件关闭请求的响应结果通过原生文件系统、用户态模块、内核态模块、虚拟文件系统，返回至用户进程。

上述所有的技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

为便于更好的实施本申请实施例的文件管理方法，本申请实施例还提供一种文件管理装置。请参阅图6，图6为本申请实施例提供的文件管理装置的结构示意图。该文件管理装置可以包括请求获取模块301，加解密确定模块302，第一路径确定模块303、第一管理模块304、第二路径确定模块305以及第二管理模块306。

请求获取模块301，用于通过用户进程获取文件访问请求。

加解密确定模块302，用于通过分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性。

在一实施例中，加解密确定模块302，具体用于通过所述分支确定模块拦截所述文件访问请求；根据所述文件路径和/或所述用户进程信息确定所述文件访问请求所需访问的待访问文件的加解密属性。

在一实施例中，文件访问请求中包括待访问文件的文件路径和/或用户进程信息，加解密确定模块302，在执行根据所述文件路径和/或所述用户进程信息确定所述文件访问请求所需访问的待访问文件的加解密属性时，具体执行：当所述文件路径属于路径黑名单中的路径时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者当所述用户进程信息属于进程黑名单中的进程信息时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者当所述文件路径和用户进程信息属于路径进程组合黑名单中的一条记录信息时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密。

第一路径确定模块303，用于当所述加解密属性表示所述待访问文件无需加解密时，确定所述待访问文件的相对路径信息。

在一实施例中，第一路径确定模块303，具体用于获取所述用户态文件系统的挂载点的基址文件描述符，所述基址文件描述符指的是所述挂载点在未挂载之前对应的文件描述符；确定所述待访问文件的相对路径；将所述基址文件描述符和所述相对路径确定为所述待访问文件的相对路径信息。

第一管理模块304，用于基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

在一实施例中，所述文件访问请求包括文件打开请求，所述第一管理模块304，具体用于基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，确定所述待访问文件的文件描述符，并打开所述待访问文件，以响应所述文件打开请求。在响应完成后的返回流程中，将待访问文件的文件描述符通过原生文件系统、虚拟文件系统返回至用户进程。

在一实施例中，所述文件访问请求包括文件读写请求（包括文件读请求和文件写请求），所述第一管理模块304，具体用于通过用户进程获取待访问文件的文件读写请求；根据待访问文件的文件描述符，通过虚拟文件系统、原生文件系统，对待访问文件进行读写，以响应文件读写请求。在响应文件读写请求完成后，将响应文件读写请求的响应结果通过原生文件系统、虚拟文件系统，返回至用户进程。

在一实施例中，所述文件访问请求包括文件关闭请求，所述第一管理模块304，具体用于通过用户进程获取待访问文件的文件关闭请求；根据待访问文件的文件描述符，通过虚拟文件系统、原生文件系统，对待访问文件进行关闭并使得待访问文件的文件描述符失效，以响应文件关闭请求。在响应文件关闭请求完成后，将响应文件关闭请求的响应结果通过原生文件系统、虚拟文件系统，返回至用户进程。

第二路径确定模块305，用于当所述加解密属性表示所述待访问文件需要加解密时，确定所述待访问文件的全路径信息。

第二管理模块306，用于基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

在一实施例中，文件访问请求包括文件打开请求，所述第二管理模块306，具体用于基于全路径信息，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，确定待访问文件的文件描述符，并打开待访问文件，以响应文件打开请求。在响应完成后的返回流程中，待访问文件的文件描述符通过原生文件系统、用户态模块、内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求包括文件读请求，所述请求获取模块301，还用于通过用户进程获取待访问文件的文件读请求；所述第二管理模块306，具体用于根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行读取，以响应文件读请求。在响应文件读请求完成后，将响应文件读请求的响应结果（读取内容）通过原生文件系统发送至用户态模块，在用户态模块中，对响应结果利用算法库进行解密，以得到解密后的响应结果，并将解密后的响应结果通过内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求包括文件写请求，所述请求获取模块301，还用于通过用户进程获取待访问文件的文件写请求，所述第二管理模块306，具体用于根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块将文件写请求发送至用户态模块，用户态模块将文件写请求所对应的写入内容进行加密处理，以得到加密处理后的写入内容，将加密处理后的写入内容通过原生文件系统写入至对应的磁盘，以响应文件写请求。在响应文件读请求完成后，将响应文件读请求的响应结果通过原生文件系统、用户态模块、内核态模块、虚拟文件系统返回至用户进程。

在一实施例中，文件访问请求包括文件关闭请求，所述请求获取模块301，还用于通过用户进程获取待访问文件的文件关闭请求，所述第二管理模块306，具体用于根据待访问文件的文件描述符，通过虚拟文件系统、内核态模块、用户态模块、原生文件系统，对待访问文件进行关闭并使得待访问文件的文件描述符失效，以响应文件关闭请求。在响应文件关闭请求完成后，将响应文件关闭请求的响应结果通过原生文件系统、用户态模块、内核态模块、虚拟文件系统，返回至用户进程。

在一实施例中，如图7所示，文件管理装置还包括创建模块307、描述符获取模块308以及保存模块309。其中，创建模块307，用于在所述计算机设备开机时，创建预设进程。描述符获取模块308，用于在所述用户态文件系统启动之前，利用预设进程来获取所述用户态文件系统的挂载点的基址文件描述符。保存模块309，用于保存所述基址文件描述符。对应地，第一路径确定模块303在执行获取所述用户态文件系统的挂载点的基址文件描述符的步骤时，具体执行：向所述预设进程发送描述符获取请求，所述描述符获取请求用于请求所述基址文件描述符；接收所述预设进程返回的所述基址文件描述符。

上述所有的技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

相应的，本申请实施例还提供一种计算机设备，该计算机设备可以为终端或者服务器。如图8所示，图8为本申请实施例提供的计算机设备的结构示意图。该计算机设备400包括有一个或者一个以上处理核心的处理器401、有一个或一个以上计算机可读存储介质的存储器402及存储在存储器402上并可在处理器上运行的计算机程序。其中，处理器401与存储器402电性连接。本领域技术人员可以理解，图中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

处理器401是计算机设备400的控制中心，利用各种接口和线路连接整个计算机设备400的各个部分，通过运行或加载存储在存储器402内的软件程序（计算机程序）和/或模块，以及调用存储在存储器402内的数据，执行计算机设备400的各种功能和处理数据，从而对计算机设备400进行整体监控。

在本申请实施例中，计算机设备400中的处理器401会按照如下的步骤，将一个或一个以上的应用程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能：

通过用户进程获取文件访问请求；

通过所述分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

当所述加解密属性表示所述待访问文件无需加解密时，确定所述待访问文件的相对路径信息；并基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

当所述加解密属性表示所述待访问文件需要加解密时，确定所述待访问文件的全路径信息；并基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

可选的，如图8所示，计算机设备400还包括：触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407。其中，处理器401分别与触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407电性连接。本领域技术人员可以理解，图8中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

触控显示屏403可用于显示图形用户界面以及接收用户作用于图形用户界面产生的操作指令。触控显示屏403可以包括显示面板和触控面板。其中，显示面板可用于显示由用户输入的信息或提供给用户的信息以及计算机设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。可选的，可以采用液晶显示器（LCD，Liquid Crystal Display）、有机发光二极管（OLED，Organic Light-EmittingDiode）等形式来配置显示面板。触控面板可用于收集用户在其上或附近的触摸操作（比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作），并生成相应的操作指令，且操作指令执行对应程序。触控面板可覆盖显示面板，当触控面板检测到在其上或附近的触摸操作后，传送给处理器401以确定触摸事件的类型，随后处理器401根据触摸事件的类型在显示面板上提供相应的视觉输出。在本申请实施例中，可以将触控面板与显示面板集成到触控显示屏403而实现输入和输出功能。但是在某些实施例中，触控面板与触控面板可以作为两个独立的部件来实现输入和输出功能。即触控显示屏403也可以作为输入单元406的一部分实现输入功能。

在本申请实施例中，该触控显示屏403用于呈现图形用户界面以及接收用户作用于图形用户界面产生的操作指令。

射频电路404可用于收发射频信号，以通过无线通信与网络设备或其他计算机设备建立无线通讯，与网络设备或其他计算机设备之间收发信号。

音频电路405可以用于通过扬声器、传声器提供用户与计算机设备之间的音频接口。音频电路405可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，传声器将收集的声音信号转换为电信号，由音频电路405接收后转换为音频数据，再将音频数据输出处理器401处理后，经射频电路404以发送给比如另一计算机设备，或者将音频数据输出至存储器402以便进一步处理。音频电路405还可能包括耳塞插孔，以提供外设耳机与计算机设备的通信。

输入单元406可用于接收输入的数字、字符信息或用户特征信息（例如指纹、虹膜、面部信息等），以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

电源407用于给计算机设备400的各个部件供电。可选的，电源407可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源407还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管图8中未示出，计算机设备400还可以包括摄像头、传感器、无线保真模块、蓝牙模块等，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条计算机程序，该计算机程序能够被处理器进行加载，以执行本申请实施例所提供的任一种文件管理方法中的步骤。例如，该计算机程序可以执行如下步骤：

通过用户进程获取文件访问请求；

通过所述分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

当所述加解密属性表示所述待访问文件无需加解密时，确定所述待访问文件的相对路径信息；并基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

当所述加解密属性表示所述待访问文件需要加解密时，确定所述待访问文件的全路径信息；并基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器（ROM，Read Only Memory）、随机存取记忆体（RAM，Random Access Memory）、磁盘或光盘等。

由于该存储介质中所存储的计算机程序，可以执行本申请实施例所提供的任一种文件管理方法中的步骤，因此，可以实现本申请实施例所提供的任一种文件管理方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种文件管理方法、装置、存储介质及计算机设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (9)

1.一种文件管理方法，应用于计算机设备中，所述计算机设备包括用户空间和内核空间，所述计算机设备的文件系统包括虚拟文件系统、用户态文件系统和原生文件系统，所述用户态文件系统包括内核态模块和用户态模块，所述虚拟文件系统、所述内核态模块、所述原生文件系统运行于所述内核空间中，用户进程、所述用户态模块、分支确定模块运行于所述用户空间中，其特征在于，包括：

通过用户进程获取文件访问请求；

通过所述分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

当所述加解密属性表示所述待访问文件无需加解密时，通过所述分支确定模块确定所述待访问文件的相对路径信息；并基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

当所述加解密属性表示所述待访问文件需要加解密时，通过所述分支确定模块确定所述待访问文件的全路径信息；并基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

其中，所述确定所述待访问文件的相对路径信息的步骤，包括：

获取所述用户态文件系统的挂载点的基址文件描述符，所述基址文件描述符指的是所述挂载点在未挂载之前对应的文件描述符；

确定所述待访问文件的相对路径；

将所述基址文件描述符和所述相对路径确定为所述待访问文件的相对路径信息。

2.根据权利要求1所述的文件管理方法，其特征在于，在所述获取所述用户态文件系统的挂载点的基址文件描述符的步骤之前，所述文件管理方法还包括：在所述计算机设备开机时，创建预设进程；

在所述用户态文件系统启动之前，利用预设进程来获取所述用户态文件系统的挂载点的基址文件描述符；

保存所述基址文件描述符。

3.根据权利要求2所述的文件管理方法，其特征在于，所述获取所述用户态文件系统的挂载点的基址文件描述符的步骤，包括：

向所述预设进程发送描述符获取请求，所述描述符获取请求用于请求所述基址文件描述符；

接收所述预设进程返回的所述基址文件描述符。

4.根据权利要求1所述的文件管理方法，其特征在于，所述文件访问请求包括所述待访问文件的文件路径和/或用户进程信息；所述通过所述分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性的步骤，包括：

通过所述分支确定模块拦截所述文件访问请求；

根据所述文件路径和/或所述用户进程信息确定所述文件访问请求所需访问的待访问文件的加解密属性。

5.根据权利要求4所述的文件管理方法，其特征在于，所述根据所述文件路径和/或所述用户进程信息确定所述文件访问请求所需访问的待访问文件的加解密属性的步骤，包括：

当所述文件路径属于路径黑名单中的路径时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者

当所述用户进程信息属于进程黑名单中的进程信息时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密；或者

当所述文件路径和用户进程信息属于路径进程组合黑名单中的一条记录信息时，确定所述文件访问请求所需访问的待访问文件的加解密属性为无需加解密；否则，确定所述文件访问请求所需访问的待访问文件的加解密属性为需要加解密。

6.根据权利要求1所述的文件管理方法，其特征在于，所述文件访问请求包括文件打开请求，所述基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，并响应所述文件访问请求的步骤，包括：

基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，确定所述待访问文件的文件描述符，并打开所述待访问文件，以响应所述文件打开请求。

7.一种文件管理装置，应用于计算机设备中，所述计算机设备包括用户空间和内核空间，所述计算机设备的文件系统包括虚拟文件系统、用户态文件系统和原生文件系统，所述用户态文件系统包括内核态模块和用户态模块，所述虚拟文件系统、所述内核态模块、所述原生文件系统运行于所述内核空间中，用户进程、所述用户态模块、分支确定模块运行于所述用户空间中，其特征在于，包括：

请求获取模块，用于通过用户进程获取文件访问请求；

加解密确定模块，用于通过分支确定模块确定所述文件访问请求所需访问的待访问文件的加解密属性；

第一路径确定模块，用于当所述加解密属性表示所述待访问文件无需加解密时，通过分支确定模块获取所述用户态文件系统的挂载点的基址文件描述符，所述基址文件描述符指的是所述挂载点在未挂载之前对应的文件描述符，确定所述待访问文件的相对路径，将所述基址文件描述符和所述相对路径确定为所述待访问文件的相对路径信息；

第一管理模块，用于基于所述相对路径信息，通过所述虚拟文件系统、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求；

第二路径确定模块，用于当所述加解密属性表示所述待访问文件需要加解密时，通过分支确定模块确定所述待访问文件的全路径信息；

第二管理模块，用于基于所述全路径信息，通过所述虚拟文件系统、所述内核态模块、所述用户态模块、所述原生文件系统，对所述待访问文件进行管理，以响应所述文件访问请求。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于处理器进行加载，以执行如权利要求1-6任一项所述的文件管理方法中的步骤。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器通过调用所述存储器中存储的所述计算机程序，执行如权利要求1-6任一项所述的文件管理方法中的步骤。

Images