CN111352900A

CN111352900A - 一种虚拟化应用文件访问方法、装置、服务器及存储介质

Info

Publication number: CN111352900A
Application number: CN202010121246.XA
Authority: CN
Inventors: 杨峰
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2020-02-26
Filing date: 2020-02-26
Publication date: 2020-06-30
Anticipated expiration: 2040-02-26
Also published as: CN111352900B

Abstract

本申请公开了一种虚拟化应用文件访问方法，在监控到虚拟化应用接收到写入请求之后，选择了将该目标文件写入对应的客户端，以使在接收到该目标文件的访问请求时，可通过访问请求重定向至客户端，使该目标文件的访问得以借助客户端本地的环境组件实现。按照上述方案执行的文件访问方案由于不面向客户端用户，因此对客户端用户将在无感知的情况下完成对该目标文件的访问，更佳方便快捷，使用体验更佳。本申请还同时公开了一种虚拟化应用文件访问装置、服务器及可读存储介质，具有上述有益效果。

Description

一种虚拟化应用文件访问方法、装置、服务器及存储介质

技术领域

本申请涉及程序虚拟化技术领域，特别涉及一种虚拟化应用文件访问方法、装置、服务器及可读存储介质。

背景技术

应用程序虚拟化(Application Virtualization)，是日益发展的虚拟化家族中的最新成员。它是一种对软件进行管理的新方式，打破应用程序、操作系统和托管操作系统的硬件之间的联系。

为了实现企业内部文件流转的监控，并且实现流转统一出入口，利用应用程序虚拟化技术，把企业需要用到的内部通信软件构建为客户端上的虚拟化应用，比如Foxmail等邮件软件、RTX(Real Time eXchange)和钉钉企业版等IM(即时通讯)类通信软件以及OA等企业业务办公软件。这些虚拟化应用实际上并未安装在客户端本地，而是采用远程应用的方式在远端服务器上进行发布并运行。

当用户通过上述虚拟化应用接收文件时，接收到的文件将被存储至虚拟化应用实际所在的服务器上。基于该虚拟化应用在完成文件接收到呈现给用户的访问页面，用户往往会直接试图进行访问，但往往该访问操作却以失败告终，进而对用户的访问造成不便。因为由于服务器作为虚拟化应用的实际运行平台，其往往并不会安装有各类型文件的运行环境，这是考虑到该虚拟化应用可能会被不同的用户群体使用，不同的用户群体对不同类型的软件需求也不一，所以在服务器上安装有支持所有类型文件远程访问的环境组件是不现实的。

因此，如何克服上述现有技术存在的技术缺陷，是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种虚拟化应用文件访问方法、装置、服务器以及可读存储介质，旨在不通过在服务端安装用于支持各类型文件访问的环境组件的前提下，为用户提供便捷的、可用的虚拟化应用文件访问服务。

为实现上述目的，本申请提供了一种虚拟化应用文件访问方法，应用于服务端，包括：

接收通过虚拟化应用传入的目标文件的写入请求；

根据所述写入请求将所述目标文件写入对应的客户端；

在接收到所述目标文件的访问请求的情况下，将所述访问请求重定向至所述客户端，以在所述客户端本地实现对所述目标文件的访问。

可选的，根据所述写入请求将所述目标文件写入对应的客户端，包括：

根据所述写入请求将所述目标文件写入所述服务端；

在接收到所述访问请求的情况下，将所述目标文件从所述服务端写入所述客户端。

根据所述写入请求直接将所述目标文件写入所述客户端。

可选的，根据所述写入请求直接将所述目标文件写入所述客户端，包括：

根据所述写入请求将默认缓存路径修改为网络缓存路径；其中，所述默认缓存路径对应所述服务端，所述网络缓存路径对应所述客户端；

将所述目标文件的所有数据按所述网络缓存路径为目的地址进行写入，得到实际存储在所述客户端的目标文件。

可选的，将所述访问请求重定向至所述客户端，包括：

根据所述访问请求确定所述网络缓存路径；

根据所述网络缓存路径确定所述目标文件所在的目标客户端；

向所述目标客户端发送访问路径为所述网络缓存路径的访问请求。

可选的，该虚拟化应用访问方法还包括：

接收所述客户端在完成所述目标文件的写入后发来的写入完成信号；

根据所述写入完成信号将所述目标文件的存储状态修改为客户端已存储；

对应的，在将所述访问请求重定向至所述客户端之前，还包括：

根据所述访问请求查询所述目标文件的存储状态；

在所述目标文件的存储状态为所述客户端已存储的情况下，执行所述将所述访问请求重定向至所述客户端的步骤。

可选的，在接收目标文件的写入请求之前，还包括：

预先向所述服务端注入文件访问重定向DLL；

利用所述文件访问重定向DLL监测所述虚拟化应用是否接收到所述写入请求；

对应的，根据所述写入请求将所述目标文件写入对应的客户端，包括：

通过所述文件访问重定向DLL根据所述写入请求将所述目标文件写入对应的客户端；

对应的，将所述访问请求重定向至所述客户端，包括：

通过所述文件访问重定向DLL将所述访问请求重定向至所述客户端。

为实现上述目的，本申请还提供了一种虚拟化应用访问装置，应用于服务端，包括：

写入请求接收单元，用于接收通过虚拟化应用传入的目标文件的写入请求；

目标文件写入单元，用于根据所述写入请求将所述目标文件写入对应的客户端；

访问请求重定向单元，用于在接收到所述目标文件的访问请求的情况下，将所述访问请求重定向至所述客户端，以在所述客户端本地实现对所述目标文件的访问。

可选的，所述目标文件写入单元包括：

服务端写入子单元，用于根据所述写入请求将所述目标文件写入所述服务端；

客户端第一写入子单元，用于在接收到所述访问请求的情况下，将所述目标文件从所述服务端写入所述客户端。

可选的，所述目标文件写入单元包括：

客户端第二写入子单元，用于根据所述写入请求直接将所述目标文件写入所述客户端。

可选的，所述客户端第二写入子单元包括：

缓存路径修改修改模块，用于根据所述写入请求将默认缓存路径修改为网络缓存路径；其中，所述默认缓存路径对应所述服务端，所述网络缓存路径对应所述客户端；

目标文件数据写入模块，用于将所述目标文件的所有数据按所述网络缓存路径为目的地址进行写入，得到实际存储在所述客户端的目标文件。

可选的，所述访问请求重定向单元包括：

缓存路径确定子单元，用于根据所述访问请求确定所述网络缓存路径；

目标客户端确认子单元，用于根据所述网络缓存路径确定所述目标文件所在的目标客户端；

访问请求重定向子单元，用于向所述目标客户端发送访问路径为所述网络缓存路径的访问请求。

可选的，该虚拟化应用访问装置还包括：

写入完成信号接收单元，用于接收所述客户端在完成所述目标文件的写入后发来的写入完成信号；

存储状态修改单元，用于根据所述写入完成信号将所述目标文件的存储状态修改为客户端已存储；

存储状态查询单元，用于在将所述访问请求重定向至所述客户端之前，根据所述访问请求查询所述目标文件的存储状态；

重定向执行单元，用于在所述目标文件的存储状态为所述客户端已存储的情况下，执行所述将所述访问请求重定向至所述客户端的步骤。

可选的，该虚拟化应用访问装置还包括：

DLL注入单元，用于在接收目标文件的写入请求之前，预先向所述服务端注入文件访问重定向DLL；

写入请求监测单元，用于利用所述文件访问重定向DLL监测所述虚拟化应用是否接收到所述写入请求；

对应的，所述目标文件写入单元包括：

DLL控制写入子单元，用于通过所述文件访问重定向DLL根据所述写入请求将所述目标文件写入对应的客户端；

对应的，所述访问请求重定向单元包括：

DLL控制重定向子单元，用于通过所述文件访问重定向DLL将所述访问请求重定向至所述客户端。

为实现上述目的，本申请还提供了一种服务器，包括：

存储器，用于存储虚拟化应用文件访问程序；

处理器，用于在执行所述虚拟化应用文件访问程序时实现如上述内容所描述的虚拟化应用文件访问方法的各步骤。

为实现上述目的，一种可读存储介质，所述可读存储介质上存储有虚拟化应用文件访问程序，所述虚拟化应用文件访问程序在被处理器执行时可实现如上述内容所描述的虚拟化应用文件访问方法的各步骤。

本申请提供的虚拟化应用文件访问方法包括：接收通过虚拟化应用传入的目标文件的写入请求；根据所述写入请求将所述目标文件写入对应的客户端；在接收到所述目标文件的访问请求的情况下，将所述访问请求重定向至所述客户端，以在所述客户端本地实现对所述目标文件的访问。

根据本申请提供的虚拟化应用文件访问方法可知，本申请在监控到虚拟化应用接收到写入请求之后，选择了将该目标文件写入对应的客户端，以使在接收到该目标文件的访问请求时，可通过访问请求重定向至客户端，使该目标文件的访问得以借助客户端本地的环境组件实现。按照上述方案执行的文件访问方案由于不面向客户端用户，因此对客户端用户将在无感知的情况下完成对该目标文件的访问，更佳方便快捷，使用体验更佳。本申请同时还提供了一种虚拟化应用文件访问装置、服务器及可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例提供的一种虚拟化应用文件访问方法的流程图；

图2为本申请实施例提供的另一种虚拟化应用文件访问方法的流程图；

图3为本申请实施例提供的一种虚拟化应用文件访问方法的时序图；

图4为本申请实施例提供的一种信号反馈和基于反馈信号判定后续操作是否具有执行基础的方法的流程图；

图5为本申请实施例提供的一种虚拟化应用文件访问装置的结构框图。

具体实施方式

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

实施例一

请参见图1，图1为本申请实施例所提供的一种云环境下服务的部署方法的流程图，其包括以下步骤，下述各步骤的执行主体均为服务端，即采用应用程序虚拟化技术得到的虚拟化应用的实际运行环境：

S101：接收通过虚拟化应用传入的目标文件的写入请求；

本步骤旨在由服务端上的虚拟化应用接收到目标文件的写入请求，其中，该目标文件可以是同样使用该虚拟化应用的其它用户发来的，例如同时有用户A和用户B在使用该虚拟化应用(例如RTX通信应用)，用户A通过该虚拟化应用构建的平台发送一个文件该平台上的用户B，当然，也可以是通过其它途径发送至该虚拟化应用，只要能够使该虚拟化应用成功接收到目标文件的写入请求即可。

S102：根据写入请求将目标文件写入对应的客户端；

在S101的基础上，本步骤旨在由服务端根据接收到的写入请求写入对应的客户端，承接上例，假定用户B为目标文件的接收者，即为将目标文件写入用户B的客户端中。

具体的，考虑到实际情况下目标文件是否会立即被访问，本步骤还可以再进行细分，其中两种可以为：

其一：根据写入请求将目标文件写入服务端；

当接收到访问请求时，将目标文件从服务端写入客户端；

其二：根据写入请求直接将目标文件写入客户端。

很明显，第一种方式是适用于一些允许接收但可能短期内不会被立即访问的文件(例如备份文件、大体积的视频文件、密钥等等)，因此为了尽可能的减少对客户端有限存储空间的占用，选择先将目标文件写入服务端，当确实接收到用户要访问、要打开该文件查询具体内容时，再将该目标文件从服务端写入客户端，以最终满足目标文件的本地访问操作；相比于第一种，第二种方式则适用于一些允许接收且可能会立即被访问的文件(例如Word、Eecel等办公常用文件)，以便于能够为用户提供更低的访问延迟。

当然，上述两种方案最终均完成了将目标文件写入客户端的目的，区别只在于写入的时机以及相应的适用场景，除上述两种之外，还存在其它介于两者之间的写入方案，即先将目标文件的一部分写入客户端(例如索引)，在被访问时再补充写入缺失的另一部分，以用于在尽可能减少占用客户端存储空间的同时，又能够降低访问延迟。

为实现这一区别于现有虚拟化应用对接收到的文件的写入操作，可通过多种方式来实现，例如在服务端植入监测插件，也可以通过诸如DLL(Dynamic Link Library，动态链接库，是一个包含可由多个程序，同时使用的代码和数据的库)注入的方式增加相应的监测功能等等，进一步的，在监测到符合预设情况的场景出现时，还可以通过赋予插件或DLL权限的方式让其能够改变后续的文件写入操作，最终实现本申请的目的。

以采用DLL注入的方式为例，可以具体选用预先将用于DLL注入至服务端的方式来实现，可包括如下步骤：

预先向服务端注入文件访问重定向DLL；

利用文件访问重定向DLL监测虚拟化应用是否接收到目标文件的写入请求。

对应的，本步骤也将具体更变为：通过文件访问重定向DLL根据写入请求将目标文件写入对应的客户端。

监测插件的植入和使用方式大体与DLL相同，只需要基于插件表现形式与DLL的不同做适应性调整，此处不再赘述。本实施例的后续步骤中由服务端执行的部分也将在文件访问重定向DLL的控制下完成。

S103：在接收到目标文件的访问请求的情况下，将访问请求重定向至客户端，以在客户端本地实现对目标文件的访问。

在S102的基础上，本步骤针对运行于服务端上的虚拟化应用接收到用户发来的目标文件访问请求的情况，通过由服务端将该访问请求重定向至客户端，以实现在客户端本地实现对目标文件的访问的目的。其中，访问请求的重定向是指将后续执行访问操作的执行者由服务端变更为客户端，这一过程可通过多种方式实现，例如在访问请求通用的情况下可直接由服务端将其转发给客户端，以使客户端基于接收到的访问请求完成后续的访问操作。

承接上例，当采用DLL注入的方式时，本步骤也将具体变更为：通过文件访问重定向DLL将访问请求重定向至客户端。

根据本实施例提供的虚拟化应用文件访问方法可知，本申请在监控到虚拟化应用接收到写入请求之后，选择了将该目标文件写入对应的客户端，以使在接收到该目标文件的访问请求时，可通过访问请求重定向至客户端，使该目标文件的访问得以借助客户端本地的环境组件实现。按照上述方案执行的文件访问方案由于不面向客户端用户，因此对客户端用户将在无感知的情况下完成对该目标文件的访问，更佳方便快捷，使用体验更佳。

实施例二

在实施例一的基础上，针对S102中提出的直接将目标文件写入对应的客户端的方案，本申请还通过图2所示流程图给出了一种较为具体的实现流程，以加深对本申请方案的理解，包括如下步骤(各步骤执行主体仍为服务端)：

S201：接收通过虚拟化应用传入的目标文件的写入请求；

S202：根据写入请求将默认缓存路径修改为网络缓存路径；

其中，默认缓存路径对应位置为服务端，网络缓存路径对应位置为客户端。

S203：将目标文件的所有数据按网络缓存路径为目的地址进行写入，得到实际存储在客户端的目标文件；

根据S202和S203可以看出，本实施例通过在接收到写入请求时修改该目标文件的缓存路径，使得目标文件得以直接写入客户端的存储空间中。

S204：在接收到目标文件的访问请求的情况下，根据访问请求确定网络缓存路径；

S205：根据网络缓存路径确定目标文件所在的目标客户端；

S206：向目标客户端发送访问路径为网络缓存路径的访问请求。

根据S204、S205以及S206可以看出，在S202和S203的基础上，重定向操作也主要通过访问路径的变更得以实现。

由于本申请方案实际上涉及客户端、服务端以及发送端，上述实施例内容仅站在服务端来描述整个方案，为便于理解，本申请还提供了包含上述三端各自执行操作的如图3所示的时序图：

1、发送端向服务端上运行的虚拟化应用发送目标文件的写入请求；

2、服务端基于接收到的写入请求控制目标文件由发送端直接写入客户端；

3、客户端向服务端上运行的虚拟化应用发送目标文件的访问请求；

4、服务端将该访问请求重定向回客户端；

5、客户端利用本地环境组件支持用户对目标文件的访问。

在上述任意实施例的基础上，考虑到访问请求的重定向要以目标文件切实被写入在客户端中为前提才可以让目标文件在客户端本地被访问，针对服务端如何确认目标文件是否完成了被写入至客户端的这一情况(尤其针对S102中提及的方式一，会导致需要等待写入)，本申请还提供了如图4所示的实现方案，包括如下步骤(各步骤执行主体仍为服务端)：

S301：接收客户端在完成目标文件的写入后发来的写入完成信号；

即说明客户端在切实接受到了完整的目标文件之后，会向服务端返回该写入完成信号。具体的，至于怎样评判是否接收到了完整的目标文件，可以通过诸如特征值验校等方式来完成，此处不再具体说明。

S302：根据写入完成信号将目标文件的存储状态修改为客户端已存储；

在S301的基础上，本步骤旨在由服务端根据接收到的写入完成信号完成对该目标文件存储状态的修改。

S303：在将访问请求重定向至客户端之前，根据访问请求查询目标文件的存储状态；

S304：在目标文件的存储状态为客户端已存储的情况下，将访问请求重定向至客户端。

S303和S304则提供了在执行访问请求重定向之前，通过查询存储状态来决定是否满足执行条件的方案。

为加深对本申请方案的理解，本申请还具体以注入DLL为例，结合具体执行细节，给出了一种更为具体的实现方案和过程：

1、用户A通过其客户端使用虚拟化通信应用(例如RTX通信软件)发送文件X给同样使用该虚拟化通信应用的用户B；

2、用户B通过该虚拟化通信应用接收到用户A发来的文件X，预先注入到该通信应用中的DLL会监控到该通信应用在默认缓存目录下创建一个文件，这时会把此默认缓存目录的路径换成客户端的一个网络缓存路径，这样就会使得该通信应用在客户端相应的缓存目录下创建一个文件；

3、该虚拟化通信应用把接收到的文件X的数据写入到该文件时，就会把数据写入到客户端对应的缓存文件中；

4、当写完文件X的所有数据后关闭此文件；

5、注入到应用程序中的DLL同时对通信应用内双击或者右键选择打开文件的行为进行监控，当监控到打开文件操作时，如果是想打开缓存目录下的文件，则把打开的行为重定向到客户端，客户端对相应的缓存文件发起双击或者右键选择打开的操作，这样用户看到的就是在客户端本地打开文件。

上述方案对应于S102中提及的方式二和实施例二，如果更换为S101中提及的方式一，则对应为：

2、用户B通过该通信应用接收到用户A发送的文件X，此时接收到的文件X是存放在服务端的该通信程序对应的默认缓存目录下；

3、注入到该通信应用中的DLL对应用内双击或者右键选择打开文件的行为进行监控，当监控到打开文件操作时，如果是想打开缓存目录下的文件，此时则把此缓存文件传输到客户端，文件传输完成之后则把打开的行为重定向到客户端，客户端对刚传输到客户端的缓存文件发起双击或者右键选择打开的操作，这样用户看到的就是在客户端本地打开文件。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图5，图5为本申请实施例提供的一种虚拟化应用文件访问装置的结构框图，该装置可以包括：

写入请求接收单元100，用于接收通过虚拟化应用传入的目标文件的写入请求；

目标文件写入单元200，用于根据写入请求将目标文件写入对应的客户端；

访问请求重定向单元300，用于在接收到目标文件的访问请求的情况下，将访问请求重定向至客户端，以在客户端本地实现对目标文件的访问。

其中，目标文件写入单元200可以包括：

服务端写入子单元，用于根据写入请求将目标文件写入服务端；

客户端第一写入子单元，用于在接收到访问请求的情况下，将目标文件从服务端写入客户端。

其中，目标文件写入单元200可以包括：

客户端第二写入子单元，用于根据写入请求直接将目标文件写入客户端。

其中，客户端第二写入子单元可以包括：

缓存路径修改修改模块，用于根据写入请求将默认缓存路径修改为网络缓存路径；其中，默认缓存路径对应服务端，网络缓存路径对应客户端；

目标文件数据写入模块，用于将目标文件的所有数据按网络缓存路径为目的地址进行写入，得到实际存储在客户端的目标文件。

其中，访问请求重定向单元300可以包括：

缓存路径确定子单元，用于根据访问请求确定网络缓存路径；

目标客户端确认子单元，用于根据网络缓存路径确定目标文件所在的目标客户端；

访问请求重定向子单元，用于向目标客户端发送访问路径为网络缓存路径的访问请求。

进一步的，该虚拟化应用访问装置还可以包括：

写入完成信号接收单元，用于接收客户端在完成目标文件的写入后发来的写入完成信号；

存储状态修改单元，用于根据写入完成信号将目标文件的存储状态修改为客户端已存储；

存储状态查询单元，用于在将访问请求重定向至客户端之前，根据访问请求查询目标文件的存储状态；

重定向执行单元，用于在目标文件的存储状态为客户端已存储的情况下，执行将访问请求重定向至客户端的步骤。

进一步的，该虚拟化应用访问装置还可以包括：

DLL注入单元，用于在接收目标文件的写入请求之前，预先向服务端注入文件访问重定向DLL；

写入请求监测单元，用于利用文件访问重定向DLL监测虚拟化应用是否接收到写入请求；

对应的，目标文件写入单元200可以包括：

DLL控制写入子单元，用于通过文件访问重定向DLL根据写入请求将目标文件写入对应的客户端；

对应的，访问请求重定向单元300可以包括：

DLL控制重定向子单元，用于通过文件访问重定向DLL将访问请求重定向至客户端。

作为与上述方法实施例对应的装置实施例，本实施例在监控到虚拟化应用接收到写入请求之后，选择了将该目标文件写入对应的客户端，以使在接收到该目标文件的访问请求时，可通过访问请求重定向至客户端，使该目标文件的访问得以借助客户端本地的环境组件实现。按照上述方案执行的文件访问方案由于不面向客户端用户，因此对客户端用户将在无感知的情况下完成对该目标文件的访问，更佳方便快捷，使用体验更佳。

基于上述实施例，本申请还提供了一种服务器，该服务器可以包括存储器和处理器，其中，该存储器中存有具体为虚拟化应用文件访问程序的计算机程序，该处理器调用该存储器中的虚拟化应用文件访问程序时，可以实现上述实施例所提供的虚拟化应用文件访问方法的各步骤。当然，该服务器还可以包括各种必要的网络接口、电源以及其它零部件等。

本申请还提供了一种可读存储介质，其上存有具体为虚拟化应用文件访问程序的计算机程序，该虚拟化应用文件访问程序被执行终端或处理器执行时可以实现上述实施例所提供的虚拟化应用文件访问方法的各步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims

1.一种虚拟化应用文件访问方法，其特征在于，应用于服务端，包括：

接收通过虚拟化应用传入的目标文件的写入请求；

根据所述写入请求将所述目标文件写入对应的客户端；

2.根据权利要求1所述的虚拟化应用访问方法，其特征在于，根据所述写入请求将所述目标文件写入对应的客户端，包括：

根据所述写入请求将所述目标文件写入所述服务端；

3.根据权利要求1所述的虚拟化应用访问方法，其特征在于，根据所述写入请求将所述目标文件写入对应的客户端，包括：

根据所述写入请求直接将所述目标文件写入所述客户端。

4.根据权利要求3所述的虚拟化应用文件访问方法，其特征在于，根据所述写入请求直接将所述目标文件写入所述客户端，包括：

5.根据权利要求4所述的虚拟化应用文件访问方法，其特征在于，将所述访问请求重定向至所述客户端，包括：

根据所述访问请求确定所述网络缓存路径；

6.根据权利要求1所述的虚拟化应用访问方法，其特征在于，还包括：

根据所述访问请求查询所述目标文件的存储状态；

7.根据权利要求1至6任一项所述的虚拟化应用访问方法，其特征在于，在接收目标文件的写入请求之前，还包括：

预先向所述服务端注入文件访问重定向DLL；

对应的，将所述访问请求重定向至所述客户端，包括：

8.一种虚拟化应用访问装置，其特征在于，用于服务端，包括：

9.一种服务器，其特征在于，包括：

存储器，用于存储虚拟化应用文件访问程序；

处理器，用于在执行所述虚拟化应用文件访问程序时实现如权利要求1至7任一项所述的虚拟化应用文件访问方法的各步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储有虚拟化应用文件访问程序，所述虚拟化应用文件访问程序在被处理器执行时可实现如权利要求1至7任一项所述的虚拟化应用文件访问方法的各步骤。