WO2022111097A1 - 一种文件更新方法及装置、设备、存储介质 - Google Patents

一种文件更新方法及装置、设备、存储介质 Download PDF

Info

Publication number
WO2022111097A1
WO2022111097A1 PCT/CN2021/123546 CN2021123546W WO2022111097A1 WO 2022111097 A1 WO2022111097 A1 WO 2022111097A1 CN 2021123546 W CN2021123546 W CN 2021123546W WO 2022111097 A1 WO2022111097 A1 WO 2022111097A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
package
directory
updated
update data
Prior art date
Application number
PCT/CN2021/123546
Other languages
English (en)
French (fr)
Inventor
王凯
Original Assignee
北京沃东天骏信息技术有限公司
北京京东世纪贸易有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京沃东天骏信息技术有限公司, 北京京东世纪贸易有限公司 filed Critical 北京沃东天骏信息技术有限公司
Priority to US18/250,554 priority Critical patent/US20230393840A1/en
Publication of WO2022111097A1 publication Critical patent/WO2022111097A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1417—Boot up procedures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0674—Disk device
    • G06F3/0676—Magnetic disk device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements

Abstract

本申请公开了一种文件更新方法，所述方法包括：下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。另外，本申请还公开了一种文件更新装置、设备及存储介质。

Description

一种文件更新方法及装置、设备、存储介质
相关申请的交叉引用
本申请基于申请号为202011351980.1、申请日为2020年11月26日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以引入方式并入本申请。
技术领域
本申请涉及计算机技术领域，涉及但不限于一种文件更新方法及装置、设备、存储介质。
背景技术
智能终端设备(如智能手机、智能音箱等)在其生命周期中，经常需要升级软件系统，一方面修复老版本缺陷，一方面升级新特性版本提升用户体验。主流在线升级方式是空中下载(Over The Air，OTA)，即设备通过移动数据或WIFI网络下载升级包，并完成升级。在完成升级包的下载后，根据升级目标和方案差异，有时需重启设备。
OTA按照升级对象可分为软件OTA(Software OTA，SOTA)和固件OTA(Firmware OTA，FOTA)。SOTA面向应用软件/APP升级，FOTA则升级引导程序(bootloader)、内核(kernel)、根目录(rootfs)等系统固件。
OTA升级的一个关键是健壮性，即OTA升级失败时仍可回退老版本，而不会导致系统或软件不可用、甚至变砖。这点对FOTA升级尤其重要。直接更新操作系统固件如kernel或rootfs，失败时很大概率导致系统无法启动和使用。
针对上述问题，业界常用方案有两种，一种是主备倒换，一种是部署“恢复(recovery)模式”。但这两种方案都需要引入额外的存储空间开销。尤其是主备倒换方案，需要额外预留一套完整系统分区空间，通常需几十、几百兆字节(MB)，甚至更多。
发明内容
有鉴于此，本申请为解决相关技术中存在的至少一个问题而提供一种文件更新方法及装置、设备、存储介质，能够在不引入额外的存储空间开销的情况下，完成文件的更新。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供一种文件更新方法，所述方法包括：
下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；
将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；
在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
第二方面，本申请实施例提供一种文件更新装置，所述装置包括：
下载单元，配置为下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；
堆叠单元，配置为将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；
写入单元，配置为在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
第三方面，本申请实施例提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述文件更新方法中的步骤。
第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述文件更新方法中的步骤。
本申请实施例中，提供了一种文件更新方法、装置、设备及存储介质，下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下；从而将对待更新文件进行更新的更新数据包下载至待更新文件包所在的磁盘空间，不需要为更新数据包提供额外的磁盘分区，且通过待更新文件包的目录和更新数据包的目录的虚拟合并，对待更新文件包和更新数据包进行堆叠，得到临时文件包，在临时文件包完成验证后，将所述更新数据包合并到所述待更新文件包的目录，完成更新数据包对待更新文件包的更新，从而在保证更新的健壮性的同时，不需要引入额外的磁盘开销。
附图说明
图1为本申请实施例提供的网络架构的可选地示意图；
图2为本申请实施例提供的文件更新方法的可选地流程示意图；
图3为本申请实施例提供的文件更新方法的可选地流程示意图；
图4为本申请实施例提供的虚拟合并文件的可选地示意图；
图5为本申请实施例提供的文件更新方法的可选地流程示意图；
图6为相关技术中文件更新方法的可选地流程示意图；
图7为相关技术中文件更新方法的可选地流程示意图；
图8为本申请实施例提供的文件更新方法的可选地流程示意图；
图9为本申请实施例提供的文件更新设备的可选地结构示意图；
图10为本申请实施例提供的文件更新方法的可选地状态转移示意图；
图11为本申请实施例提供的文件更新方法的可选地流程示意图；
图12为本申请实施例提供的虚拟合并文件的可选地示意图；
图13为本申请实施例提供的文件更新装置的可选地结构示意图；
图14为本申请实施例提供的电子设备的可选地结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对申请的技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。
本申请实施例可提供为文件更新方法及装置、设备和存储介质。实际应用中，文件更新方法可由文件更新装置实现，文件更新装置中的各功能实体可以由计算机设备的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。
本申请实施例的文件更新方法可应用于图1所示的信息处理系统，如图1所示，该信息处理系统包括客户端10和服务端20；其中，客户端10中安装有能够进行从网络侧下载更新数据包并对待更新文件包进行更新的文件管理程序。服务端20能够基于更新文件生成更新数据包，并将更新数据包发送至客户端10，客户端基于下载的数据包对待更新文件包进行更新。客户端10和服务端20之间通过网络30进行交互。
客户端10可实施为实现文件更新方法的文件更新装置。客户端10从服务端20下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
在一示例中，服务端10为云端服务器。
结合图1所示的应用场景示意图，本申请实施例提出一种文件更新方法，能够在不引入额外的存储空间开销的情况下，完成文件的更新。
下面，结合图1所示的信息处理系统的示意图，对本申请实施例提供的文件更新方法、装置、设备和存储介质的各实施例进行说明。
本实施例提供一种文件更新方法，该方法应用于文件更新设备，文件更新设备可为客户端，其中，客户端可为计算机设备。该方法所实现的功能可以通过计算机设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该计算机设备至少包括处理器和存储介质。
图2为本申请实施例的一种文件更新方法的实现流程示意图，如图2所示，该方法可以包括如下步骤：
S201、文件更新设备下载更新数据包至待更新文件包所在的目标磁盘分区。
所述更新数据包用于对所述待更新文件包进行更新。
这里，将更新数据包中的文件称为更新文件，将待更新文件包中的文件称为待更新文件。更新数据包中的包括至少一个更新文件，待更新文件包中包括至少一个待更新文件。
文件更新设备在等待状态下，从服务端下载更新数据包。本申请实施例中，基于文件更新的场景不同，下载的更新数据包不同。在文件升级场景下，下载的更新数据包为升级包，可称为OTA升级包。在文件回退场景下，下载的更新数据包为回退包，可称为OTA回退包。
本申请实施例提供的文件更新方法应用的场景不限制在文件升级、文件回退场景，也可用于其他对文件更新设备中的文件进行更新的场景下。
更新数据包和待更新文件包属于同一应用程序的文件包，也可为同一文件系统中的固件。
文件更新设备在下载更新数据包之前，确定待更新数据包所在的目标磁盘分区，将更新数据包下载至确定的目标磁盘分区中。在一示例中，目标磁盘分区为根文件系统rootfs。
本申请实施例中，更新数据包的目录的布局与待更新文件包的目录的布局相同。
在一示例中，更新数据包的目录下包括：目录1和目录2，其中，目录1下包括文件1、文件2，目录2下包括文件3；待更新文件包中的待更新文件包括：文件3、文件4、文件5、文件6，待更新文件包的目录下包括子目录：目录1和目录2，目录1下包括文件4和文件5，目录2下包括文件3和文件6。
本申请实施例中，对于同名文件，在更新数据包中的全路径与在待更新文件包中的全路径相同，
在一示例中，更新数据包中目录包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件File-1，目录Dir-B下的文件包括：文件File-4，文件File-1和File4在更新数据包中的全路径分别为:/Dir-A/File-1、/Dir-B/File4；待更新文件包中目录包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件File-1和文件File-2，目录Dir-B下的文件包括：文件File-3，此时，文件File-1至File3在待更新文件包的全路径分别为:/Dir-A/File-1，/Dir-A/File-2，/Dir-B/File-3。
本申请实施例中，文件更新设备可在完成更新数据包的下载后，进入下载完成状态，并在下载完成状态下执行一次重启。
S202、文件更新设备将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包。
根据所述待更新文件包的目录和所述更新数据包的目录，调用所述待更新文件包中的待更新文件和所述更新数据包中的更新文件，对待更新文件包和更新数据包进行堆叠，得到临时文件包。
文件更新设备在执行一次重启的过程中，根据待更新文件包的目录和所述更新数据包的目录，对待更新文件包和更新数据包进行堆叠。这里，文件更新设备将更新数据包的目录和待更新文件包的目录进行虚拟合并，得到新的文件目录，即挂载目录，并基于挂载目录，调用更新数据包中各个更新文件和待更新文件包中各待更新文件，得到临时文件包。
本申请实施例中，在调用更新文件和待更新文件时，基于更新文件的更新方式，调用的文件不同，其中，更新方式包括：替换、删除、新增和保持等几种情况。对于待更新文件包和更新数据包 中都有且路径相同的文件，更新方式为替换，即使用更新数据包中文件替换/覆盖待更新文件包中的同名文件；对于更新数据包中有但待更新文件包中没有的新增文件，更新方式为新增；对于更新数据包中没有涉及的文件，在未明确标识下，更新方式为保持，即使用待更新文件包中文件；对于更新数据包中没有涉及的文件，且明确标识的需要删除的文件，更新方式为删除。这里，标识文件是否删除的标记可在更新包配置参数中配置。本申请实施例中，可在更新包配置参数中配置各更新文件的更新方式。
在虚拟合并过程中，在更新方式为替换时，将该文件在更新数据包中的路径添加到挂载目录中，在更新方式为新增时，将该文件在更新数据包中的路径添加到挂载目录中，当更新方式为保持时，将该文件在待更新文件包中的路径添加到挂载目录中，当更新方式为删除时，将该文件在待更新文件包中的路径隐藏，不添加到挂载目录中。
本申请实施例中，在进行更新数据包的目录和待更新文件包的目录的虚拟合并时，仅将各文件的路径进行合并，对文件本身不进行替换、删除等处理。
在实际应用中，文件更新设备可在完成待更新文件所在的根文件系统的挂载之后，且在改变根目录至根文件系统之前，进行待更新文件包的目录和更新数据包的目录的虚拟合并，得到临时文件包。
这里，对于用户而言，能看到的临时文件包与预期得到的目标文件包相同，但临时文件包中所包括的文件在底层文件系统如根文件系统中，且临时文件包中属于更新数据包的文件位于更新数据包所在的目录下，属于待更新文件包的文件位于待更新文件包所在的目录下，即更新数据包与待更新文件包并未进行实际合并。
文件更新设备在得到临时文件包后，对临时文件包进行验证。本申请实施例中，对临时文件包进行验证的验证方式可包括：执行文件读写、服务检测等临时文件包的部分功能，也可将临时文件包的版本信息与待更新文件包对应的版本信息进行比对，确定是否进行升级。其中，对临时文件包进行验证的验证方式可根据实际需求进行设定，本申请实施例验证方式不进行任何的限定。
当文件更新设备确定临时文件包验证成功后，进入验证成功状态，触发二次重启，并执行S203，当文件更新设备确定临时文件包验证失败后，将所述更新数据包删除。
这里，文件更新设备将更新数据包删除后，执行二次重启，加载待更新文件所在的根文件系统，完成系统的恢复。
S203、文件更新设备在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
文件更新设备在临时文件包验证成功的情况下，执行二次重启，在二次重启过程中，在完成目标磁盘分区的挂载之后，且在根目录改变至根文件系统之前，将更新数据包写入待更新文件包所在的目录下，将更新数据包与待更新文件包进行合并，以通过更新数据包对待更新文件包进行更新。
这里，当写入更新数据包时，根据各更新文件对应的更新方式对待更新文件包中的待更新文件进行处理。当更新方式为替换，将文件名相同的更新文件对待更新文件进行覆盖；当更新方式为保 持，则对待更新文件不进行修改，当更新方式为添加，将更新文件添加到待更新文件包中；当更新方式为删除，将待更新文件删除。
通过更新数据包对待更新文件包的更新，得到目标文件包。
本申请实施例提供的文件更新方法支持以下场景的系统文件的更新。
场景一、对应用程序(APP)的系统文件进行更新，系统文件可包括：基本命令bin文件、lib库文件等。
场景二、系统级更新，此时，更新的文件为整个rootfs的版本文件。
因此，本申请实施例提供的文件更新方法能够同时支持APP和系统级更新。
本申请实施例提供的文件更新方法，下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下；从而将对待更新文件进行更新的更新数据包下载至待更新文件包所在的磁盘空间，不需要为更新数据包提供额外的磁盘分区，且通过待更新文件包的目录和更新数据包的目录的虚拟合并，对待更新文件包和更新数据包进行堆叠，得到临时文件包，在临时文件包完成验证后，将所述更新数据包合并到所述待更新文件包的目录，完成更新数据包对待更新文件包的更新，从而在保证更新的健壮性的同时，不需要引入额外的磁盘开销。
在一些实施例中，S201的实施包括：下载所述更新数据包至所述目标磁盘空间的第一空间区域；所述待更新文件包位于所述目标磁盘空间的第二空间区域。
这里，目标磁盘空间为底层文件系统rootfs，更新数据包和待更新文件包都位于rootfs中，且位于不同的空间区域使得更新数据包的目录和待更新文件包的目录为独立的目录。
在一些实施例中，在S202之前，检测到所述更新数据包下载完成，设置引导加载程序中的第一升级参数为第一值，并生成第一重启指令；所述第一值指示所述更新数据包完成下载；基于所述第一重启指令，执行一次重启；
对应的，S202的实施包括：检测到所述第一升级参数为所述第一值，将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包。
当第一升级参数为第一值，则第一升级参数指示当前文件更新设备为更新数据包下载完成状态，当文件更新设备在重启过程中，检测到第一升级参数为第一值，则将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包。
这里，文件更新设备可在完成待更新文件所在的根文件系统的挂载之后，且在改变根目录至根文件系统之前，检测第一升级参数的值。
在一些实施例中，如图3所示，S202的实施包括：
S2021、将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到挂载目录；
S2022、基于所述挂载目录，调用所述待更新文件包和所述更新数据包，得到所述临时文件包。
在本申请实施例中，将更新数据包的目录作为上层目录，将待更新文件包的目录作为下层目录， 通过堆叠文件系统技术将上层目录和下层目录进行虚拟合并，将上层目录对应的文件夹和下层目录对应的文件夹合并到同一个目录中。其中，堆叠文件系统技术可为unionfs、aufs、overlayfs等。这里，将合并后的目录称为挂载目录，并基于挂载目录调用挂载目录中位于上层目录中的更新文件和位于下层文件中的待更新文件。
在一些实施例中，S2021的实施包括：
将所述更新数据包的目录下第一文件的路径添加到所述挂载目录；所述第一文件和所述待更新文件包的目录下的第二文件为同名文件；将所述更新数据包的目录下第三文件的路径添加到所述挂载目录，所述第三文件为所述更新数据包相对于所述待更新文件包所新增的文件；将所述待更新文件包的目录下的第四文件添加到所述挂载目录；所述第四文件为所述待更新文件包的目录下保持的文件。
这里，将更新方式涉及替换、删除、新增、保持等几种情况，在进行虚拟合并时，遍历更新数据包中的文件，与待更新文件包中的同路径文件对比：对于待更新文件包和升级数据包中都有且路径相同的同名文件(更新数据包中的第一文件，待更新文件包中的第二文件)，即更新方式为替换，将第一文件的路径添加到挂载目录中；对于待更新文件包中没有的新增文件即第三文件，即更新方式为新增，将第三文件的路径添加到挂载目录中；对于更新数据包中没有涉及的文件，且需要使用的文件即第四文件，即更新方式为保持，将第四文件的路径添加到挂载目录中；对于更新数据包中没有涉及的文件，但标识需要删除的文件即第五文件，即更新方式为删除，将第五文件的路径隐藏，不会添加到挂载目录中。
在一示例中，如图4所示，更新数据包的目录为目录402，待更新文件包的目录为目录403，将目录402和目录403虚拟合并至挂载目录401，其中，目录402包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件4011，目录Dir-B下的文件包括：文件4014，目录403包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件4012，目录Dir-B下的文件包括：文件4013。其中，文件4011对应的更新方式为替换，则将目录402中的文件4011的路径添加至挂载目录401中，文件4012对应更新方式为保持，则将目录403中的文件4012的路径添加至挂载目录401中，文件4013对应更新方式为删除，则将文件4013的路径不添加至挂载目录401中，文件4014对应的更新方式为添加，则将文件4014的路径不添加至挂载目录401中。此时，挂载目录下的目录包括：Dir-A和Dir-B，Dir-A下的文件包括文件4011和文件4012，Dir-B下的文件包括文件4014。
在一些实施例中，在S203之前，所述文件更新方法还包括：
检测到调用的文件验证成功，设置引导加载程序中的第二升级参数为第二值，并生成第二重启指令；所述第二值指示所述调用的文件验证成功；
基于所述第二重启指令，执行二次重启；
相应的，S203的实施包括：检测到所述第二升级参数为所述第二值，将所述更新数据包写入所述待更新文件包的目录下。
当第二升级参数为第二值，则第二升级参数指示当前文件更新设备为验证成功状态，当文件更 新设备在重启过程中，检测到第二升级参数为第二值，则将所述更新数据包与待更新文件包进行合并，以通过更新数据包对待更新文件包进行更新。
这里，文件更新设备可在完成待更新文件所在的根文件系统的挂载之后，且在改变根目录至根文件系统之前，检测第二升级参数的值。
在实际应用中，第一升级参数与第二升级参数可为同一参数。
在一些实施例中，如图5所示，S203的实施包括：
S2031、将所述更新数据包中的第一文件覆盖所述待更新文件包中的第二文件；
所述第一文件与所述第二文件同名；
S2032、将所述更新数据包中的第三文件写入所述待更新文件包的目录下；
所述第三文件为所述更新数据包中除所述第一文件之外的文件。
S2033、将所述待更新文件包中的第五文件删除。
所述第五文件为所述待更新文件包中待删除的文件。
这里，更新方式涉及替换、删除、新增、保持等几种情况，在进行并时，遍历更新数据包中的文件，与待更新文件包中的同路径文件对比：对于待更新文件包和升级数据包中都有且路径相同的同名文件(更新数据包中的第一文件，待更新文件包中的第二文件)，即更新方式为替换，将第一文件覆盖第二文件；对于待更新文件包中没有的新增文件即第三文件，即更新方式为新增，将第三文件添加到待更新文件包中；对于更新数据包中没有涉及的文件，且需要使用的文件即第四文件，即更新方式为保持，保持第四文件不变；对于更新数据包中没有涉及的文件，但标识需要删除的文件即第五文件，即更新方式为删除，将第五文件从待更新数据包中删除。
在一示例中，更新数据包的目录为目录402，待更新文件包的目录为目录403，将目录402和目录403虚拟合并至挂载目录401，其中，目录402包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件4011，目录Dir-B下的文件包括：文件4014，目录403包括：目录Dir-A和目录Dir-B，且，目录Dir-A下的文件包括：文件4012，目录Dir-B下的文件包括：文件4013。其中，文件4011对应的更新方式为替换，通过目录402中的文件4011替换目录403中的文件4011，文件4012对应更新方式为保持，则保持文件4012不变，文件4013对应更新方式为删除，则将文件4013删除，文件4014对应的更新方式为添加，则将目录402中的文件4014添加到目录403中。
下面，以文件升级为文件更新的场景为例，对本申请实施例提供的文件更新方法进行进一步说明。
为保证文件升级的健壮性，常用的OTA方案包括：主备倒换和部署“recovery模式”。
采用主备倒换的文件升级的原理如图6所示，磁盘预留两个完整系统分区：主动(active)系统和被动(passive)系统，每个完整系统分区包括：内核(kernel)、临时根文件系统(initrd)和根文件系统(rootfs)。当当前应用active系统，在下载升级包后直接更新另一分区passive系统，并通过设置参数通知引导程序(bootloader)，重启后切换到新系统分区passive系统，完成升级。
如图6所示，文件升级过程包括三个阶段：正常启动阶段、升级安装阶段和重启阶段。文件升 级过程包括：
S601、引导active系统，下载OTA升级包。
S602、安装OTA升级包，更新passive系统。
S603、通知bootloader主备倒换。
S604、重启后，引导新active系统即更新后的passive系统。
采用部署“recovery模式”的文件升级的原理如图7所示，磁盘预留一个精简分区：recovery系统，且recovery系统包括kernel和initrd的有限功能，设备下载升级包后先重启进入recovery系统，再更新正常系统分区，完成后触发重启进入正常系统。如果升级失败，则通过进入recovery模式重新升级版本进行恢复。
如图7所示，文件升级过程包括三个阶段：正常启动阶段、升级阶段和重启阶段。文件升级过程包括：
S701、引导正常系统，下载OTA升级包。
S702、启动recovery系统。
S703、安装OTA升级包，更新正常系统。
S704、重启后，引导更新后的正常系统。
上述两种文件升级方案为保障升级过程健壮性，均引入额外存储空间开销。尤其是主备倒换方案，额外预留一套完整系统分区空间，通常需几十、几百MB，甚至更多。此问题在智能手机等大容量存储设备中并不突出，但在低成本物联网智能设备中，存储空间的额外消耗影响相对较大。
为解决上述方案存在的问题，本申请实施例提供一种文件升级方法，在保证OTA升级健壮性同时，消除额外预留磁盘空间。
本申请实施例提供的文件升级方法如图8所示，磁盘空间包括本身具有的引导程序、正常系统和用户数据分区等磁盘分区之外，并不需要额外的磁盘空间。其中，正常系统包括：kernel、initrd和rootfs。
如图8所示，本申请实施例提供的文件升级方法的升级过程包括四个阶段：下载阶段、一次重启阶段、回退阶段和二次重启阶段。文件升级过程包括：
S801、下载OTA升级包。
在下载阶段，下载OTA升级包。下载的OTA升级包存储在磁盘分区中的根文件系统中，其中，待升级的原文件也存储在根文件系统中。在完成OTA升级包后，设备引导程序中的升级参数为下载完成状态，并触发重启，进入一次重启阶段。
S802、通过文件目录的虚拟合并，对OTA升级包进行升级校验。
在第一次重启过程中，initrd中的OTA主模块读取到升级参数为下载完成状态，则利用堆叠文件系统技术，应用OTA包(虚拟合并，不替换)。
这里，在第一次重启，未切换根文件系统之前，进行堆叠挂载，使OTA升级包的目录和原文件包目录进行“虚拟合并”，以应用OTA包即临时文件包。
若应用OTA包失败，设置升级参数为验证失败状态，触发二次重启，进入失败回退阶段，并执行S803。
若应用OTA包成功，改变根目录后进入根文件系统，执行OTA包的验证。当验证成功，则设置升级参数为验证成功状态，触发二次重启，进入失败回退阶段，并执行S803；当验证失败，则设置升级参数为验证失败状态，触发二次重启，进入二次重启阶段，并执行S804。
S803、系统回退。
进入失败回退阶段的二次重启过程中，initrd中的OTA主模块读取到升级参数为验证失败状态，则删除OAT升级包，取消堆叠文件系统调用，加载原根文件系统，回退原系统。
S804、文件替换。
在二次重启阶段的二次重启过程中，initrd中的OTA主模块读取到升级参数为验证成功状态，则触发版本替换，读取OTA升级包，并将读取OTA的升级包写入原文件所在的目录，以替换原文件。在完成原文件的替换、新增、删除等文件包合并后，改变根目录为rootfs，加载文件更新后的rootfs。
本申请实施例提供的文件更新方法所应用的信息系统的结构如图9所示，包括：云端901和设备端902。其中，云端901的组件包括：升级包制作组件9011，设备端902的组件包括：OTA下载9021、OTA验证9022、OTA主模块9023、OTA参数存储9024。其中，
升级包制作9011，配置为制作OTA升级包。
OTA下载9021，位于stystem/rootfs，配置为从云端下载OTA升级包。
OTA验证9022，位于stystem/rootfs，配置为对OTA包进行验证。
OTA主模块9023，位于initrd，配置为控制OTA包的应用、验证和替换。
OTA参数存储9024，位于bootloader，配置为存储升级参数。
本申请实施例提供的文件更新方法中文件更新设备的状态转移图如图10所示，文件更新设备的状态包括：等待状态1001、下载完成状态1002、升级验证状态1003、验证成功状态1004和验证失败状态1005。
在等待状态1001下，下载OTA升级包，下载OTA升级包成功，则进入下载完成状态1002，下载OTA升级包失败，停留在等待状态1001。
在下载完成状态1002下，设置升级参数，执行一次重启，并触发升级验证，进入升级验证状态1003。
在升级验证状态1003下，进行升级验证，当升级验证成功，则进入验证成功状态1004，当升级验证失败，则进入验证失败状态1005。
在验证成功状态1004下，执行二次重启，完成文件替换，加载新系统。新系统中待更新的文件已替换为新文件。
在验证失败状态1005下，执行二次重启，取消新系统，加载原系统。原系统中为待更新的文件即原文件。
本申请实施例提供的文件更新方法如图11所示，包括：
S1101、等待。
S1102、下载OTA升级包。
S1103、判断OTA升级包是否下载成功？
在下载成功的情况下，执行S1104，在下载失败的情况下，执行S1101。
S1104、OTA升级验证。
文件更新设备通过堆叠文件系统技术对OTA升级的目录和原文件的目录进行虚拟合并，得到挂载目录，并基于挂载目录调用OTA升级包和原文件，得到OTA包，对OTA包进行验证。
S1105、是否升级验证成功？
在验证成功的情况下，执行S1106，在验证成功的情况下，执行S1107。
S1106、更新系统。
通过OTA升级包对系统中原文件进行替换，得到升级后的文件，并执行二次重启，加载新系统。
S1107、恢复原系统。
删除OTA升级包，执行二次重启，加载原系统。
本申请实施例中，OTA升级包的制作和升级验证中采用了堆叠文件系统技术，采用的堆叠文件系统技术可为unionfs、aufs、overlayfs等。堆叠文件系统技术的技术原理如图12所示，lower dirA1203、lower dirB1204和upper dir1202分别为来自底层文件系统的不同目录，用户可以自行指定，内部包含了用户想要合并的文件和目录，merge dir1201为挂载点。当文件系统挂载后，在merge dir1201下将会同时看到来自各lower dir A1203、lower dirB1204和upper dir1202下的内容，其中，在merge dir1201会看到来自upper dir1202的文件A和文件B、来自lower dir A1203的文件C以及来自lower dirB1204的文件D。并且用户也无法(无需)感知这些文件分别哪些来自lower dir，哪些来自upper dir，用户看见的只是一个普通的文件系统根目录而已，其中，lower dir可以有多个也可以只有一个。
upper dir和各lower dir这几个不同的目录并不完全等价，存在层次关系。当upper dir和lower dir两个目录存在同名文件时，lower dir的文件将会被隐藏，用户只能看见来自upper dir的文件，例如，图12中，lower dirA1203和upper dir1202中都包括有文件B，用户只能看到来自upper dir1202中的文件B，将lower dirA1203中的文件B隐藏。各个lower dir也存在相同的层次关系，较上层屏蔽较下层的同名文件，例如，图12中，lower dirA1203和lower dirB1204中都包括有文件C，用户只能看到来自lower dirA120中的文件C，将lower dirB1204中的文件C隐藏。除此之外，如果存在同名的目录，那就继续合并。
在upper目录和lower目录均存在的文件(同名文件的全路径一致)，只有upper dir目录下的文件会在“虚拟合并”后的目录中显示，upper dir中不存在的文件，可显示为lower dir中文件或标记为删除不显示，比如：当标识为不删除时，则显示为lower dir中文件，当标识为删除时，则删除不显示。本申请基于该技术特点，将新版本文件的目录和老版本文件的目录分别作为不同的目录，比如：upper dir和lower dir，根据新老版本差异，生成OTA升级包。在OTA测试时，使用“虚拟合并”技术进行测试和验证。
本申请实施例提供的文件更新方法包括：
S11、OTA软件包制作；
云端对比两个版本目录差异，基于堆叠文件系统技术，制作OTA升级包；必要的，对OTA升级包进行安全加固，如签名、加密等。
S12、OTA软件包下载；
设备端利用已有安全通道和机制，下载OTA升级包。必要的，对OTA升级包进行安全校验，如验签、解密等。
S13、设置升级参数为下载完成状态。
OTA升级包下载完成后，利用OTA参数存储模块接口(典型如bootloader env分区/变量设置)，更新升级参数指示的OTA状态为下载完成状态，触发一次重启。
S14、应用OTA包；
一次重启后，执行到initrd中的OTA主模块。OTA主模块读取到的升级参数为下载完成状态，触发OTA升级测试验证。
这里，设备端在挂载根文件系统(mount system/rootfs)之后，改变至根文件系统(chroot system/rootfs)之前，使用堆叠文件系统，对根文件系统(system/rootfs)进行二次挂载(mount)，对OTA升级包的目录已经和老版本文件的目录进行“虚拟合并”。如二次mount失败，设置升级参数为验证失败状态，触发二次重启。
如二次mount成功，设备端继续执行chroot system/rootfs，执行完必要初始化后，启动OTA验证服务。验证服务执行基本和用户定制的验证过程(如文件读写、服务检测、版本对比等)，当验证成功，则设置升级参数为验证成功状态，当验证成功，则设置升级参数为验证失败状态。触发二重启。
本申请实施例中，initrd为临时文件系统，主要目的是进行系统初始化，最终通过mount和chroot的操作要切换到根文件系统，切换过程一般是两步：第一步、mount根文件系统(所在磁盘分区)，第二步是chroot切换根目录到刚才mount的节点。一次mount是必要操作，是将根文件系统所在磁盘分区进行挂载，挂载后系统才可以识别根文件系统中的内容。本申请实施例中，在一次mount之后和chroot之前，执行了二次mount，以得到临时文件包。
S15、进行文件替换。
设备端二次重启后，再次执行到initrd的OTA主模块。OTA主模块读取升级参数为验证成功状态，则触发系统更新/版本替换。
这里，在mount system/rootfs之后，chroot system/rootfs之前，设备端使用OTA升级包目录文件替换、新增或删除system/rootf目录下的文件即原系统文件。删除OTA升级包，释放磁盘空间，得到新系统。更新升级参数为等待状态。执行chroot，切换到新系统，完成文件的升级。
S16、回复原系统。
设备端二次重启后，再次执行到initrd的OTA主模块。OTA主模块，读取升级参数为验证失败 状态，则触发恢复系统服务。
这里，设备端记录相关错误信息，删除OTA升级包目录，直接mount system/rootfs，更新状态为“等待”，执行chroot，恢复为原系统。
本申请实施例提供的文件更新方法，具有以下特点：
1、无需为OTA升级预留额外磁盘分区，提升系统磁盘利用率。
2、基于堆叠文件系统技术的OTA升级包制作、应用方法，保证更新过程的健壮性，通过“虚拟合并”，即能够进行升级校验，也可在mount失败或校验失败时，恢复旧系统，这是直接替换方式所实现不了的技术效果。
图13为本申请实施例的一种文件更新装置的实现流程示意图，如图13所示，装置1300包括：
下载单元1301，配置为下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；
堆叠单元1302，配置为将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；
写入单元1303，配置为在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
在一些实施例中，下载单元1301，还配置为：
下载所述更新数据包至所述目标磁盘空间的第一空间区域；所述待更新文件包位于所述目标磁盘空间的第二空间区域。
在一些实施例中，装置1300还包括：
第一重启单元，配置为：
在将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包之前，检测到所述更新数据包下载完成，设置引导加载程序中的第一升级参数为第一值，并生成第一重启指令；所述第一值指示所述更新数据包完成下载；基于所述第一重启指令，执行一次重启；
相应的，堆叠单元，还配置为检测到所述第一升级参数为所述第一值，将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包。
在一些实施例中，堆叠单元1302，还配置为：
将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到挂载目录；
基于所述挂载目录，调用所述待更新文件包和所述更新数据包，得到所述临时文件包。
在一些实施例中，堆叠单元1302，还配置为：
将所述更新数据包的目录下第一文件的路径添加到所述挂载目录；所述第一文件和所述待更新文件包的目录下的第二文件为同名文件；
将所述更新数据包的目录下第三文件的路径添加到所述挂载目录，所述第三文件为所述更新数据包相对于所述待更新文件包所新增的文件；
将所述待更新文件包的目录下的第四文件添加到所述挂载目录；所述第四文件为所述待更新文件包的目录下保持的文件。
在一些实施例中，装置1300还包括：第二重启单元，配置为：
在将所述更新数据包合并到所述待更新文件包的目录下之前，检测到所述临时文件包验证成功，设置引导加载程序中的第二升级参数为第二值，并生成第二重启指令；所述第二值指示所述临时文件包验证成功；
基于所述第二重启指令，执行二次重启；
相应的，写入单元1303，还配置为检测到所述第二升级参数为所述第二值，将所述更新数据包合并到所述待更新文件包的目录下。
在一些实施例中，写入单元1303，还配置为：
将所述更新数据包中的第一文件覆盖所述待更新文件包的目录下的第二文件；所述第一文件与所述第二文件同名；
将所述更新数据包中的第三文件写入所述待更新文件包的目录下；所述第三文件为所述更新数据包中除所述第一文件之外的文件；
将所述待更新文件包中的第五文件删除，所述第五文件为所述待更新文件包中待删除的文件。
在一些实施例中，装置1300还包括：
回退单元，配置为在所述临时文件包验证失败的情况下，将所述更新数据包删除。
需要说明的是，本申请实施例提供的文件更新装置包括所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central Processing Unit)、微处理器(MPU，Micro Processor Unit)、数字信号处理器(DSP，Digital Signal Processor)或现场可编程门阵列(FPGA，Field-Programmable Gate Array)等。
以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的文件更新方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
对应地，本申请实施例提供一种电子设备即计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的文件更 新方法。其中，该电子设备可为客户端，也可为服务端。
对应地，本申请实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的文件更新方法中的步骤。
这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，图14为本申请实施例电子设备的一种硬件实体示意图，如图14所示，所述电子设备1400包括：一个处理器1401、至少一个通信总线1402、至少一个外部通信接口1404和存储器1405。其中，通信总线1402配置为实现这些组件之间的连接通信。在一示例中，电子设备1400还包括：用户接口1403、其中，用户接口1403可以包括显示屏，外部通信接口1404可以包括标准的有线接口和无线接口。
存储器1405配置为存储由处理器1401可执行的指令和应用，还可以缓存待处理器1401以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以 是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (11)

  1. 一种文件更新方法，所述方法包括：
    下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；
    将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；
    在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
  2. 根据权利要求1所述的方法，其中，所述下载更新数据包至待更新文件包所在的目标磁盘分区，包括：
    下载所述更新数据包至所述目标磁盘空间的第一空间区域；所述待更新文件包位于所述目标磁盘空间的第二空间区域。
  3. 根据权利要求1所述的方法，其中，在将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包之前，所述方法还包括：
    检测到所述更新数据包下载完成，设置引导加载程序中的第一升级参数为第一值，并生成第一重启指令；所述第一值指示所述更新数据包完成下载；
    基于所述第一重启指令，执行一次重启；
    相应的，检测到所述第一升级参数为所述第一值，将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包。
  4. 根据权利要求1所述的方法，其中，所述将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包，包括：
    将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到挂载目录；
    基于所述挂载目录，调用所述待更新文件包和所述更新数据包，得到所述临时文件包。
  5. 根据权利要求4所述的方法，其中，所述将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到挂载目录，包括：
    将所述更新数据包的目录下第一文件的路径添加到所述挂载目录；所述第一文件和所述待更新文件包的目录下的第二文件为同名文件；
    将所述更新数据包的目录下第三文件的路径添加到所述挂载目录，所述第三文件为所述更新数据包相对于所述待更新文件包所新增的文件；
    将所述待更新文件包的目录下的第四文件添加到所述挂载目录；所述第四文件为所述待更新文件包的目录下保持的文件。
  6. 根据权利要求1所述的方法，其中，在将所述更新数据包合并到所述待更新文件包的目录下之前，所述方法还包括：
    检测到所述临时文件包验证成功，设置引导加载程序中的第二升级参数为第二值，并生成 第二重启指令；所述第二值指示所述临时文件包验证成功；
    基于所述第二重启指令，执行二次重启；
    相应的，检测到所述第二升级参数为所述第二值，将所述更新数据包合并到所述待更新文件包的目录下。
  7. 根据权利要求1所述的方法，其中，所述将所述更新数据包合并到所述待更新文件包的目录下，包括：
    将所述更新数据包中的第一文件覆盖所述待更新文件包中的第二文件；所述第一文件与所述第二文件同名；
    将所述更新数据包中的第三文件写入所述待更新文件包的目录下；所述第三文件为所述更新数据包中除所述第一文件之外的文件；
    将所述待更新文件包中的第五文件删除；所述第五文件为所述待更新文件包中待删除的文件。
  8. 根据权利要求1所述的方法，其中，所述方法还包括：
    在所述临时文件包验证失败的情况下，将所述更新数据包删除。
  9. 一种文件更新装置，所述装置包括：
    下载单元，配置为下载更新数据包至待更新文件包所在的目标磁盘分区；所述更新数据包用于对所述待更新文件包进行更新；
    堆叠单元，配置为将所述待更新文件包的目录和所述更新数据包的目录进行虚拟合并，得到临时文件包；
    写入单元，配置为在所述临时文件包验证成功的情况下，将所述更新数据包合并到所述待更新文件包的目录下。
  10. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至8任一项所述文件更新方法中的步骤。
  11. 一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现权利要求1至8任一项所述的文件更新方法。
PCT/CN2021/123546 2020-11-26 2021-10-13 一种文件更新方法及装置、设备、存储介质 WO2022111097A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/250,554 US20230393840A1 (en) 2020-11-26 2021-10-13 File update method and apparatus, device and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011351980.1 2020-11-26
CN202011351980.1A CN112463191A (zh) 2020-11-26 2020-11-26 一种文件更新方法及装置、设备、存储介质

Publications (1)

Publication Number Publication Date
WO2022111097A1 true WO2022111097A1 (zh) 2022-06-02

Family

ID=74808939

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/123546 WO2022111097A1 (zh) 2020-11-26 2021-10-13 一种文件更新方法及装置、设备、存储介质

Country Status (3)

Country Link
US (1) US20230393840A1 (zh)
CN (1) CN112463191A (zh)
WO (1) WO2022111097A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116909998A (zh) * 2023-09-12 2023-10-20 海马云（天津）信息技术有限公司 overlay文件系统下文件的处理方法和装置

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112463191A (zh) * 2020-11-26 2021-03-09 北京沃东天骏信息技术有限公司 一种文件更新方法及装置、设备、存储介质
CN113110865A (zh) * 2021-04-21 2021-07-13 北京字跳网络技术有限公司 一种服务器热更新方法及装置
CN113238772B (zh) * 2021-04-29 2024-02-23 联合汽车电子有限公司 程序更新方法、域控制器以及存储介质
CN113312073B (zh) * 2021-06-15 2022-05-27 上海益世界信息技术集团有限公司广州分公司 一种安装包文件处理方法和相关装置
CN113852717B (zh) * 2021-09-27 2024-03-19 努比亚技术有限公司 一种壁纸模块位置迁移方法、设备及计算机可读存储介质
CN116048644B (zh) * 2023-03-30 2023-06-16 中科方德软件有限公司 一种系统迁移方法、装置和可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040093597A1 (en) * 2002-11-05 2004-05-13 Rao Bindu Rama Firmware update system for facilitating firmware update in mobile handset related applications
CN103777987A (zh) * 2014-01-26 2014-05-07 宝龙计算机系统（湖南）有限公司 一种类unix操作系统的升级方法及装置
CN109542493A (zh) * 2017-09-22 2019-03-29 华为技术有限公司 一种镜像升级方法及设备
CN109634645A (zh) * 2018-12-28 2019-04-16 深圳市有方科技股份有限公司 固件升级方法及终端
CN110018994A (zh) * 2017-11-02 2019-07-16 华为终端有限公司 更新文件系统的方法、网络设备及计算机可读存储介质
US20200356358A1 (en) * 2019-05-07 2020-11-12 Dell Products L.P. Systems and methods for incrementally and dynamically updating firmware
CN112463191A (zh) * 2020-11-26 2021-03-09 北京沃东天骏信息技术有限公司 一种文件更新方法及装置、设备、存储介质
CN112631832A (zh) * 2020-12-23 2021-04-09 苏州三六零智能安全科技有限公司 文件系统数据卷更新方法、终端设备、存储介质及装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7549042B2 (en) * 2003-12-16 2009-06-16 Microsoft Corporation Applying custom software image updates to non-volatile storage in a failsafe manner
EP2270805A3 (en) * 2004-07-22 2011-01-26 Panasonic Corporation Playback apparatus for performing application-synchronized playback
US7756821B2 (en) * 2006-11-02 2010-07-13 Microsoft Corporation Virtual deletion in merged file system directories
CN101957765B (zh) * 2010-09-02 2016-01-20 北京中星微电子有限公司 一种实现设备固件更新的方法及系统、设备
CN103218248B (zh) * 2013-03-25 2016-12-28 华为技术有限公司 一种虚拟机镜像的更新方法、服务器和桌面云系统
CN106021373A (zh) * 2016-05-11 2016-10-12 北京神州绿盟信息安全科技股份有限公司 一种文件更新方法及装置
CN107861686B (zh) * 2017-09-26 2021-01-05 深圳前海微众银行股份有限公司 文件存储方法、服务端和计算机可读存储介质
US10789062B1 (en) * 2019-04-18 2020-09-29 Dell Products, L.P. System and method for dynamic data deduplication for firmware updates

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040093597A1 (en) * 2002-11-05 2004-05-13 Rao Bindu Rama Firmware update system for facilitating firmware update in mobile handset related applications
CN103777987A (zh) * 2014-01-26 2014-05-07 宝龙计算机系统（湖南）有限公司 一种类unix操作系统的升级方法及装置
CN109542493A (zh) * 2017-09-22 2019-03-29 华为技术有限公司 一种镜像升级方法及设备
CN110018994A (zh) * 2017-11-02 2019-07-16 华为终端有限公司 更新文件系统的方法、网络设备及计算机可读存储介质
CN109634645A (zh) * 2018-12-28 2019-04-16 深圳市有方科技股份有限公司 固件升级方法及终端
US20200356358A1 (en) * 2019-05-07 2020-11-12 Dell Products L.P. Systems and methods for incrementally and dynamically updating firmware
CN112463191A (zh) * 2020-11-26 2021-03-09 北京沃东天骏信息技术有限公司 一种文件更新方法及装置、设备、存储介质
CN112631832A (zh) * 2020-12-23 2021-04-09 苏州三六零智能安全科技有限公司 文件系统数据卷更新方法、终端设备、存储介质及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116909998A (zh) * 2023-09-12 2023-10-20 海马云（天津）信息技术有限公司 overlay文件系统下文件的处理方法和装置
CN116909998B (zh) * 2023-09-12 2023-12-12 海马云（天津）信息技术有限公司 overlay文件系统下文件的处理方法和装置

Also Published As

Publication number Publication date
US20230393840A1 (en) 2023-12-07
CN112463191A (zh) 2021-03-09

Similar Documents

Publication Publication Date Title
WO2022111097A1 (zh) 一种文件更新方法及装置、设备、存储介质
US10606800B1 (en) Policy-based layered filesystem management
KR100750132B1 (ko) 부팅, 소프트웨어 자동 업데이트 및 에러 복원 방법과 그시스템, 그 방법을 기록한 컴퓨터 판독 가능한 기록매체
JP4901095B2 (ja) 不揮発性ストレージにカスタム・ソフトウェア・イメージ・アップデートを適用するフェイルセーフな方法
JP5113700B2 (ja) ファームウェア更新装置及び方法
WO2019019643A1 (zh) 应用程序热更新方法、装置、终端和存储介质
US8752039B1 (en) Dynamic upgrade of operating system in a network device
CN110286930B (zh) 一种云平台升级方法、装置、终端及存储介质
US20110041124A1 (en) Version Management System
EP3769224B1 (en) Configurable recovery states
CN113805914B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN113032032B (zh) 一种系统管理方法、装置、计算设备及可读存储介质
CN103677937A (zh) 升级软件和运行软件的方法及装置
CN114780019A (zh) 电子设备的管理方法、装置、电子设备及存储介质
CN113326078A (zh) 一种动态更新软件开发工具包的方法、设备及存储介质
CN111338751B (zh) 同ceph集群中数据跨pool迁移方法及装置
CN116594639A (zh) 系统安装包的管理方法、设备、存储介质及程序产品
CN113032183A (zh) 系统管理方法、装置、计算机设备和存储介质
CN106933604B (zh) 一种系统升级方法及装置
EP3769225B1 (en) Free space pass-through
CN110221868B (zh) 主机系统的部署方法、装置、电子设备及存储介质
CN112579113A (zh) 应用程序的升级方法、装置、存储介质及终端
US20240054000A1 (en) Container scheduling and deployment method and apparatus, and domain controller system
CN117687663B (zh) 基于ota的分区动态调整方法、装置、设备及存储介质
US11762756B2 (en) System and method for startup data verification

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21896599

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 14/09/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21896599

Country of ref document: EP

Kind code of ref document: A1