CN116107510A - File management method, device and storage medium - Google Patents

File management method, device and storage medium Download PDF

Info

Publication number
CN116107510A
CN116107510A CN202310089413.0A CN202310089413A CN116107510A CN 116107510 A CN116107510 A CN 116107510A CN 202310089413 A CN202310089413 A CN 202310089413A CN 116107510 A CN116107510 A CN 116107510A
Authority
CN
China
Prior art keywords
file
storage
partition
storage space
subfiles
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202310089413.0A
Other languages
Chinese (zh)
Inventor
李香林
王鑫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang Dahua Technology Co Ltd
Original Assignee
Zhejiang Dahua Technology Co Ltd
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 Zhejiang Dahua Technology Co Ltd filed Critical Zhejiang Dahua Technology Co Ltd
Priority to CN202310089413.0A priority Critical patent/CN116107510A/en
Publication of CN116107510A publication Critical patent/CN116107510A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • G06F3/0643Management of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604Improving or facilitating administration, e.g. storage management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • G06F3/0644Management of space entities, e.g. partitions, extents, pools

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application discloses a file management method, a device and a storage medium. The file management method comprises the steps of obtaining the file size of a data file and the residual storage space of a plurality of storage partitions; if the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, splitting the data file into a plurality of subfiles according to the descending order of the sizes of the residual storage spaces of a plurality of storage partitions; and storing the plurality of subfiles in the corresponding storage partition according to the file size of each subfile. According to the embodiment, when the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, the data file is split according to the descending order of the sizes of the residual storage spaces so as to store the data, so that the data file can be stored quickly, and subsequent operations such as reading the data file can be facilitated.

Description

File management method, device and storage medium
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a file management method, device, and storage medium.
Background
With the continuous development of information technology, terminal devices have become an indispensable component in life of people, and the terminal devices implement corresponding functions by configuring an operating system.
The software mechanism responsible for managing and storing file information in an operating system is called a file management system, which is called a file system for short. From a system perspective, a file system is a system that organizes and allocates file memory space (e.g., hard disk, magnetic disk, or partition, etc.), takes care of storing files, and protects and retrieves stored files. Specifically, the file system is responsible for creating files for users, storing, reading out, modifying, dumping files, controlling access to files, revoking files when users are no longer using, etc.
In order to facilitate the management of files by users, the storage space of the system is generally partitioned, each partition is used for storing files of a corresponding class, the storage space of each partition is consumed along with the long-term use process of terminal equipment, at this time, if a larger file needs to be stored, the storage space of a single partition is difficult to meet the storage requirement, and the large file can be stored in a packaging library so as to realize the access of the file.
Disclosure of Invention
In order to solve the above technical problems in the prior art, the present application provides a file management method, device and storage medium.
In order to solve the above problems, the present application provides a file management method, which includes obtaining a file size of a data file and remaining storage spaces of a plurality of storage partitions; if the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, splitting the data file into a plurality of subfiles according to the descending order of the sizes of the residual storage spaces of the storage partitions; and storing the plurality of subfiles in corresponding storage partitions according to the file size of each subfile.
In order to solve the above-mentioned problem, the present application provides a file management apparatus, including: a processor and a memory, the memory storing a computer program, the processor being configured to execute the computer program to implement the method described above.
To solve the above-described problems, the present application provides a computer-readable storage medium having stored thereon program instructions that, when executed by a processor, implement the above-described method.
Compared with the prior art, the file management method comprises the steps of obtaining the file size of a data file and the residual storage space of a plurality of storage partitions; if the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, splitting the data file into a plurality of subfiles according to the descending order of the sizes of the residual storage spaces of a plurality of storage partitions; and storing the plurality of subfiles in the corresponding storage partition according to the file size of each subfile. According to the embodiment, when the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, the data file is split according to the descending order of the sizes of the residual storage spaces so as to store the data, so that the data file can be stored quickly, and subsequent operations such as reading the data file can be facilitated.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic structural diagram of an embodiment of file storage performed by a linux operating system provided in the present application;
FIG. 2 is a schematic diagram illustrating the structure of a universal catalog of the Linux operating system according to an embodiment of the present application;
FIG. 3 is a flowchart illustrating an embodiment of a method for file management provided herein;
FIG. 4 is a flowchart illustrating an embodiment after the step S303 in FIG. 3;
FIG. 5 is a flowchart illustrating an embodiment after the step S403 in FIG. 4;
FIG. 6 is a flowchart illustrating the step S502 in FIG. 5;
FIG. 7 is a flowchart illustrating another embodiment of a file management method provided herein;
FIG. 8 is a flowchart illustrating the step S703 of FIG. 7;
FIG. 9 is a schematic structural diagram of an embodiment of a document management apparatus provided in the present application;
FIG. 10 is a schematic diagram illustrating the structure of an embodiment of a document management apparatus provided herein;
fig. 11 is a schematic structural diagram of an embodiment of a computer storage medium provided in the present application.
Detailed Description
The present application is described in further detail below with reference to the drawings and examples. It is specifically noted that the following examples are only for illustration of the present application, but do not limit the scope of the present application. Likewise, the following embodiments are only some, but not all, of the embodiments of the present application, and all other embodiments obtained by one of ordinary skill in the art without inventive effort are within the scope of the present application.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
In the description of the present application, it should be noted that, unless explicitly stated and limited otherwise, the terms "mounted," "disposed," "connected," and "connected" are to be construed broadly, and may be, for example, fixedly connected, detachably connected, or integrally connected; the connection can be mechanical connection or electric connection; may be directly connected or may be connected via an intermediate medium. It will be apparent to those skilled in the art that the foregoing is in the specific sense of this application.
The file management method can be applied to terminal equipment such as computers and the like, and in order to facilitate file management of the terminal equipment, the terminal equipment is configured with an operating system to realize corresponding functions. The software mechanism in the operating system responsible for managing and storing file information is referred to as a file management system. From a system perspective, a file system is a system that organizes and allocates file memory space (e.g., hard disk, magnetic disk, or partition, etc.), takes care of storing files, and protects and retrieves stored files. Specifically, the file system is responsible for creating files for users, storing, reading out, modifying, dumping files, controlling access to files, revoking files when users are no longer using, etc. In this embodiment, taking an operating system as a linux operating system as an example, referring to fig. 1, fig. 1 is a schematic structural diagram of an embodiment of storing files by using the linux operating system provided in the present application.
As shown, in the linux operating system, it can be divided into three parts, a storage demand side, a storage supply side, and a file system side. The storage demand side is used for software operation, data generated during the software operation can be stored in the storage supply side through the file system side, and data required to be read during the software operation can be read from the storage supply side through the file system side. The storage supply side is used for storing data and providing data read by software, and comprises an information file and a storage area, wherein the storage area can be divided into a plurality of storage partitions, such as partition A, partition B, partition C and the like. The information file may then be used to record information such as each available partition, and the remaining storage space in the partition. The file system side may include a virtual file system (virtual File System, VFS) and a user space file system (Filesystem in Userspace, FUSE). As the Linux operating system kernel supports the FUSE characteristic, compared with other file systems, the file system does not need to compile a Linux kernel, only needs to load a FUSE module by the kernel, and realizes a relevant file system processing interface defined by FUSE in a user mode.
The software process is arranged on the storage demand side, and in the process of allowing software, data needs to be stored, and the data needs to be stored in a lasting mode through a file writing mode. And the software process uses a Posix-API mode of the Linux standard to conduct file read-write operation. Different programming languages, although different in use, ultimately realize file access by the file management mode of the Linux operating system. The storage supply side is a specific implementation of a user mode file system, and the APP process takes over and gathers all usable storage resources by the Linux operating system for reading and writing the file, centrally manages the storage resources and accesses data of software.
Referring to fig. 2, fig. 2 is a schematic structural diagram of an embodiment of a general directory of the Linux operating system provided in the present application.
As shown in fig. 2, the universal catalog of the Linux operating system includes: bin, etc, lib, mnt, proc, sbin, sys, tmp, usr, var. In order to make each software on the storage requirement side have an independent similar environment, a folder can be used as a root directory of a program by using a Linux color mode, as shown in the figure, in this embodiment, two software (APP-a and APP-B) are respectively configured with an independent similar environment, and each similar environment includes a directory: bin, etc, lib, mnt, proc, sbin, sys, tmp, usr, var. Each path has a different read-write attribute, e.g., bin, etc, lib, mnt, proc, sbin, sys is a folder with read-only attribute, not allowing data to be written; while tmp, usr, var is a readable and writable folder, files can be added and deleted to the folder, as well as modifications to the contents of the files. Different folders have different characteristics, such as: the usr folder is a directory where a user can access data permanently, and the tmp folder is a directory where a user accesses data temporarily, and the data is automatically lost after the program exits or the device is powered off.
The APP operates in an independent environment, performs file operation through a standard Linux-Posix-API, and the VFS file system of the Linux endosome forwards a response request to the FUSE to realize real data access. To reduce the load of FUSE on data access, FUSE can take over only writable folders in the APP's independent environment, and otherwise directly use the mount-bind approach of this example (mount one directory to another directory, e.g./tmp/APP 1/bin folder can bind Host/bin).
In the above embodiments, the operating system is mainly exemplified as a Linux operating system, and in other embodiments, the operating system may also be other operating systems, for example, a mac operating system, an embedded operating system, and so on.
Based on the above technical basis, the present application provides a file management method, and referring to fig. 3, fig. 3 is a schematic flow chart of an embodiment of the file management method provided in the present application, and specifically includes the following steps S301 to S303.
Step S301: the file size of the data file and the remaining storage space of the plurality of storage partitions are obtained.
The data file may be a file generated by the software during use, for example, a file generated by a user editing an associated file of the software. The file size of a data file is a measure of the size of a computer file, typically expressed in prefixed bytes, and is illustratively 10GB, 15GB, 5GB, etc. The terminal device may include a storage area, where the storage area is divided into a plurality of storage partitions, and the storage area may be divided into storage partitions such as usr, data, others, where each storage partition has an independent storage space, and as the terminal device is used for a long period of time, the storage space of each partition may be consumed, where the size of the remaining storage space of each storage partition may be obtained, and the original storage space of the usr storage partition is 100GB, the original storage space of the data storage partition is 150GB, the original storage space of the other storage partition is 200GB, and after the terminal device is used, the original remaining storage space of the usr storage partition is 5GB, the original remaining storage space of the data storage partition is 6GB, and the original remaining storage space of the other storage partition is 7GB.
Step S302: if the file size of the data file is larger than the remaining storage space of each storage partition and smaller than the sum of the remaining storage spaces of all the storage partitions, splitting the data file into a plurality of subfiles according to a descending manner of the sizes of the remaining storage spaces of the plurality of storage partitions.
After the file size of the data file and the residual storage space of a plurality of storage partitions are obtained, the file size of the data file and the residual storage space size of the storage partitions can be calculated and compared, and when the file size of the data file is smaller than or equal to the residual storage space of a certain storage partition, the data file is directly stored in the storage partition. When the file size of the data file is larger than the remaining storage space of each storage partition, the data file cannot be stored in a certain storage partition completely, the sum of the remaining storage spaces of all the storage partitions can be calculated, and when the file size of the data file is smaller than the sum of the remaining storage spaces of all the storage partitions, the data file can be split into a plurality of subfiles, and then the subfiles are stored in a partitioned mode. In order to reduce the number of subfiles as much as possible, the data file may be split into subfiles in a manner that the sizes of the remaining storage spaces of the storage partitions decrease.
For example, when the size of the data file is 10GB and the terminal device includes three memory partitions, the remaining memory space of the first memory partition is 5GB, the remaining memory space of the second memory partition is 6GB, and the remaining memory space of the third memory partition is 7GB. At this time, the data file can be split into two subfiles of 7GB and 3GB, so as to reduce the number of split subfiles as much as possible.
Step S303: and storing the plurality of subfiles in the corresponding storage partition according to the file size of each subfile.
After splitting the data file into multiple subfiles, then several subfiles are stored in corresponding memory partitions according to the file size of each subfile, illustratively the data file is 10GB in size and split into two subfiles of 7GB and 3 GB. The residual storage space of the first storage partition is 5GB, the residual storage space of the second storage partition is 6GB, and the residual storage space of the third storage partition is 7GB, and then the subfiles of 7GB are stored in the storage partition with the residual storage space of 7 GB; at this time, since the remaining storage space of the first storage partition is 5GB and the remaining storage space of the second storage partition is 6GB, both of which are greater than 3GB of subfiles, 3GB of subfiles may be stored in the storage partition having the remaining storage space of 6GB, or 3GB of subfiles may be stored in the storage partition having the remaining storage space of 5 GB.
According to the embodiment, when the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, the data file is split according to the descending order of the sizes of the residual storage spaces so as to store the data, so that the data file can be stored quickly, and subsequent operations such as reading the data file can be facilitated.
Referring to fig. 4, fig. 4 is a schematic flow chart of an embodiment after step S303 in fig. 3, specifically, the following steps S401 to S403 are included.
Step S401: and if the data file is detected to be required to be displayed, opening all subfiles from the storage partition.
Whether the data file needs to be displayed or not may be determined in response to an operation instruction of a user, and when the data file needs to be displayed is detected, a sub-file is opened from each storage partition. And when the subfiles are opened, corresponding file information can be searched from the information file according to the related path information of the opened files, wherein the file information can comprise offset positions, file sizes, position identifiers of pointers and the like.
Step S402: its offset location in the data file is read from each subfile.
The step of reading the offset position of each sub-file in the data file may be before or after the sub-file is opened, that is, there may be no explicit order between step S402 and step S403. The offset location may refer to the location of each subfile throughout the data file, illustratively, three subfiles are opened from the storage partition, the offset location of the first subfile being used to refer to the first subfile being in the middle of the data file, the offset location of the second subfile being used to refer to the first subfile being in the beginning of the data file, and the offset location of the third subfile being used to refer to the first subfile being in the end of the data file.
Step S403: and restoring all the subfiles according to the offset positions to display the data file.
After determining the offset position, all subfiles are restored according to the offset position, and the data file is obtained and displayed. Illustratively, three subfiles are opened from the storage partition, and the offset position of the first subfile, the offset position of the second subfile, and the offset position of the third subfile are respectively the middle part of the data file, the beginning position of the data file, and the end of the data file, so that the data file is spliced according to the sequence of the second subfile, the first subfile, and the third subfile.
In one embodiment, after all subfiles are restored according to the offset position to display the data file (step S403), the file management method further includes: acquiring a position identifier of a command pointer in the data file before splitting the data file into a plurality of subfiles; the command pointer is displayed in the data file based on the location identification. The command pointer is a tool for determining that data needs to be input, the position identifier is used for referring to the position of the command pointer, the command pointer exists in the data before the data is split, and at this time, the position of the command pointer can be recorded, and when a data file is to be displayed, the command pointer is also displayed at the position identifier. In other embodiments, the command pointer may also be displayed directly at the beginning of the data file or at the end of the data file when the data file is opened; or can also receive the operation instruction of the user and adjust the position of the command pointer.
In one embodiment, after all subfiles are restored according to the offset position to display the data file (step S403), the file management method further includes: responding to an operation instruction for closing the data file, and acquiring the file sizes of the subfiles stored in all the storage partitions; if the free partition with zero file size of the subfiles exists in the storage partition, deleting the folder used for storing the subfiles in the free partition. After the data read-write is completed, closing the file, after the file is closed, detecting the file size of each partition sub-file, and deleting the folder used for storing the sub-file in the idle partition when the file size is zero.
Further, when closing the data file, the position of the command pointer may be detected, the target sub-file may be determined based on the position, and all sub-files behind the target sub-file may be deleted. Illustratively, when the command pointer remains in the second subfile, all subfiles following the second subfile are deleted. Meanwhile, after deleting the subfiles, file information can be saved, for example, one opened data file is 90KB, which is divided into 3 subfiles (30 KB, 30KB respectively), and the software reopens the file and overwrites only 50KB, so the change is made to subfile 1 (30 KB) and subfile 2 (20 KB), and subfile 3 is deleted.
Referring to fig. 5, fig. 5 is a flowchart of an embodiment after step S403 in fig. 4, specifically, the following steps S501 to S502 are included.
Step S501: and if the writing of the new data in the data file is detected, acquiring the writing position of the new data in the data file.
After the data file is opened, the data file may be modified, for example, new data may be written in the data file, so that the total file of the data file becomes larger. The writing location may be which subfile the newly added data is located in, e.g., the writing location is in the first subfile, or the second subfile, etc. The writing position can be determined according to the position of the command pointer, that is, the command pointer is in the first subfile, and the writing position is in the first subfile.
Step S502: the newly added data is stored in a storage partition based on the write location and the storage partitions of the number of subfiles.
It may be further determined in which partition the new data should be stored by obtaining the size of each memory partition and the writing location, so that the new data is stored. For example, when the newly added data is in the first sub-file and the storage partition storing the first sub-file has the remaining storage space, the newly added data may be stored in the storage partition; when the storage partition of the first group file does not have remaining storage space, the newly added data may be stored in the other storage partition.
Referring to fig. 6, fig. 6 is a flowchart of an embodiment of step S502 in fig. 5, specifically, the following steps S601 to S603 are included.
Step S601: and determining the target subfile where the writing position is located and the first storage partition where the target subfile is located.
After determining the writing position of the newly added data in the data file, the newly added file is stored. The writing position is a target sub-file where the position of the newly added data is located, for example, the writing position is in a first sub-file, and the first sub-file is the target sub-file. After determining the target subfile, a first storage partition stored by the target subfile may be determined.
Step S602: and if the first storage partition has residual storage space, storing the newly added data in the first storage partition.
And monitoring whether the first storage partition has the residual storage space in real time, and when the first storage partition has the residual storage space, storing the new data in the first storage partition in real time in the process of writing the new data.
Step S603: and if the first storage partition has no residual storage space and the second storage partition has residual storage space, storing the newly added data in the second storage partition, wherein the second storage partition comprises other storage partitions in which the subfiles are stored.
When it is detected that the first storage partition has no remaining storage space and there is remaining storage space in the second storage partition, newly written newly added data cannot be stored in the first storage partition, and in order to reduce the number of data file storage partitions, the newly added data is stored in the second storage partition with subfiles in real time.
In an embodiment, the file management method further includes: if the second storage partition has no residual storage space, and the third storage partition which does not store the subfiles has residual storage space; selecting a target storage partition with the largest residual storage space from the third storage partition to store newly-added data; if the target storage partition has no remaining storage space and the newly-added data which is not stored still exists, returning to the step, if the second storage partition has no remaining storage space and the third storage partition which does not store the subfiles has remaining storage space, until the newly-added data is stored.
After the new data is stored in all the second storage partitions with the subfiles and still written, at this time, one target storage partition with the largest residual storage space in the third storage partition can be selected for storing the written new data, so as to reduce the splitting number of the new files as much as possible. When the target storage partition does not have the storage space, the target storage partition can be regarded as the second storage partition, and the step is returned to, if the second storage partition does not have the residual storage space, and the third storage partition which does not have the subfiles has the residual storage space, namely, whether other third storage partitions have the residual storage space is detected again, if so, the third storage partition with the largest residual storage space is selected as the target storage partition to store the data, and the step is repeated until all newly added data are completely stored.
Referring to fig. 7, fig. 7 is a flowchart of another embodiment of the file management method provided in the present application, specifically, including the following steps S701 to S703.
Step S701: the file order between all subfiles is determined based on the offset position of each subfile in the data file.
The offset location may refer to a location of each sub-file in the entire data file, after the offset location of each sub-file is obtained, a file order among all the sub-files may be determined, for example, three sub-files are opened from the storage partition, where the offset location of the first sub-file is used to refer to a first sub-file at a beginning location of the data file, the offset location of the second sub-file is used to refer to a second sub-file at a middle location of the data file, the offset location of the third sub-file is used to refer to a third sub-file at an end of the data file, and the order of the three sub-files is the first sub-file, the second sub-file, and the third sub-file.
Step S702: and acquiring the file sizes and the residual storage spaces of the subfiles of all the storage partitions.
The step of obtaining the file sizes and the remaining storage spaces of the subfiles of all the storage partitions may be before determining the file order among all the subfiles, or may be after determining the file order among all the subfiles, that is, there may be no explicit order between step S702 and step S701. The file sizes of the subfiles of the storage partitions of all the files and the related information of the residual storage space can be stored in one information file, and when the related information is needed, the related information can be directly called in the information file.
Step S703: and merging all the subfiles according to the file sequence, the file size and the residual storage space.
After the data file is stored, operations such as reading and writing of the data file may be performed, during which the size of the data file in each storage partition may be changed, for example, after the data file is deleted, the subfiles of the storage partition may be reduced, and at this time, in order to reduce the number of subfiles, a plurality of subfiles may be combined. Meanwhile, the plurality of subfiles are combined according to the sequence among the subfiles, so that the sequence disorder of the subfiles is reduced as much as possible, and the operation difficulty in the process of opening the data file in the later period is simplified.
Referring to fig. 8, fig. 8 is a flowchart of an embodiment of step S703 in fig. 7, specifically, including the following steps S801 to S802.
Step S801: if the remaining storage space of the N storage partition where the N sub-file in the file sequence is located is greater than or equal to the file size of the N+1st sub-file in the file sequence, storing the N+1st sub-file in the N storage partition, and updating the remaining storage space of the N storage partition, wherein N is a natural number greater than 1.
The remaining storage space of the nth storage partition and the file size of the n+1th sub-file can be obtained from the information file, and compared, and when the remaining storage space of the nth storage partition is greater than or equal to the file size of the n+1th sub-file, the n+1th sub-file is stored in the nth storage partition. N is a natural number greater than 1, i.e., the Nth subfile may be the first subfile in the file order. Taking the nth sub-file as the first sub-file as an example, when the remaining storage space of the first sub-file is greater than or equal to the file size of the second sub-file in the file sequence, it is stated that the second sub-file and the first sub-file may be merged into the first storage partition storing the first sub-file, and after merging, the remaining storage space of the first storage partition may be updated, so as to continuously check whether the remaining storage space of the first storage partition can also merge the third sub-file.
Step S802: and if the updated residual storage space of the N storage partition is greater than or equal to the file size of the (N+2) th subfile in the file sequence, storing the (N+2) th subfile in the N storage partition, and updating the residual storage space of the N storage partition.
After updating the remaining storage space of the nth storage partition, the remaining storage space of the nth storage partition and the file size of the n+2 sub-file can be continuously obtained, the remaining storage space of the nth storage partition and the file size of the n+2 sub-file are compared, and when the remaining storage space of the nth storage partition is greater than or equal to the file size of the n+2 sub-file, the n+2 sub-file is stored in the nth storage partition. Taking the nth sub-file as the first sub-file as an example, when the first storage partition stores the second sub-file, the remaining storage partition of the first storage partition is compared with the file size of the third sub-file, and when the remaining storage partition of the first storage partition is larger than the file size of the third sub-file, it is indicated that the third sub-file and the first sub-file can be combined into the first storage partition, and after the combination, the remaining storage space of the first storage partition can be updated so as to continuously check whether the remaining storage space of the first storage partition can still be combined with the fourth sub-file.
The act of merging the storage subfiles in the first storage space is repeated until all subfiles are merged into the first storage partition, or the first storage partition cannot merge other subfiles.
In an embodiment, the file management method may further include: if the remaining storage space of the N storage partition where the N sub-file is located in the file sequence is smaller than the file size of the N+1 sub-file in the file sequence, comparing the remaining storage space of the N+1 storage partition where the N+1 sub-file is located with the file size of the N+2 sub-file; if the remaining storage space of the N+1th storage partition where the N+1th subfile in the file sequence is located is greater than or equal to the file size of the N+2th subfile in the file sequence, storing the N+2th subfile in the N+1th storage partition, and updating the remaining storage space of the N+1th storage partition; if the updated residual storage space of the n+1th storage partition is greater than or equal to the file size of the n+3rd subfile in the file sequence, storing the n+3rd subfile in the n+1th storage partition, and updating the residual storage space of the n+1th storage partition.
The remaining storage space of the nth storage partition and the file size of the n+1 sub-file can be obtained from the information file, and compared, when the remaining storage space of the nth storage partition is smaller than the file size of the n+1 sub-file, the nth storage partition cannot accommodate the n+1 sub-file. At this time, the remaining storage space of the n+1th storage partition where the n+1th sub-file is located may be compared with the file size of the n+2th sub-file, and when the remaining storage space of the n+1th storage partition is smaller than the file size of the n+2th sub-file, the comparison is continued until the remaining storage space of the n+2th storage partition is found to be larger than the file size of the sub-file stored in the storage space adjacent thereto, and then the sub-file is stored in the storage space. And if the remaining storage space of the N+1th storage partition is larger than or equal to the file size of the N+2th subfile, storing the N+2th subfile in the N+1th storage partition, and if the updated remaining storage space of the N+1th storage partition is larger than or equal to the file size of the N+3rd subfile in the file sequence, storing the N+3rd subfile in the N+1th storage partition. And repeating the action of merging the storage subfiles of the N+1th storage partition until all other subfiles except the N-th subfile are merged into the N+1th storage partition, or the N+1th storage partition cannot merge other subfiles.
In an embodiment, the file management method further includes: if the updated residual storage space of the N storage partition is smaller than the file size of the N+2 sub-file in the file sequence, comparing the residual storage space of the N+2 storage partition where the N+2 sub-file is located with the file size of the N+3 sub-file; if the remaining storage space of the n+2th storage partition where the n+2th subfile in the file sequence is located is greater than or equal to the file size of the n+3rd subfile in the file sequence, storing the n+3rd subfile in the n+2th storage partition, and updating the remaining storage space of the n+2th storage partition.
After the N+2-th storage partition stores the N+2-th subfile, the remaining storage space is smaller than the file size of the N+2-th subfile, and at the moment, the N+2-th subfile is not merged into the N-th storage space, but the remaining storage space of the N+2-th storage partition is directly compared to determine whether the remaining storage space is larger than the file size of the N+3-th subfile, and if the remaining storage space of the N+2-th storage partition is larger than or equal to the file size of the N+3-th subfile, the N+3-th subfile is stored in the N+2-th storage partition. Taking N as 1 st example, when the first storage space can merge the second sub-file, the remaining storage space cannot merge the third sub-file, and the second storage space can merge the third sub-file, then merge the third sub-file into the second storage space, when the second storage space can merge the fourth sub-file, then continue to merge the fourth sub-file, repeat this step until all the sub-files are merged into the second storage partition, or the second storage partition cannot merge other sub-files; when the second storage space can not merge the third sub-file, detecting whether the third storage space can merge the fourth sub-file, if so, merging, and if not, continuing to detect whether the next storage space can merge the sub-files of the adjacent storage space. Repeating the steps until all the files are traversed.
According to the embodiment, when the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, the data file is split according to the descending order of the sizes of the residual storage spaces so as to store the data, so that the data file can be stored quickly, and subsequent operations such as reading the data file can be facilitated.
The file management method in the embodiment can be applied to a file management device, and the file management device can be a server, a mobile device or a system formed by mutually matching the server and the mobile device. Accordingly, each part included in the mobile device, for example, each unit, sub-unit, module, and sub-module, may be all disposed in the server, may be all disposed in the mobile device, and may also be disposed in the server and the mobile device, respectively.
Further, the server may be hardware or software. When the server is hardware, the server may be implemented as a distributed server cluster formed by a plurality of servers, or may be implemented as a single server. When the server is software, it may be implemented as a plurality of software or software modules, for example, software or software modules for providing a distributed server, or may be implemented as a single software or software module, which is not specifically limited herein.
In order to implement the file management method of the above embodiment, the present application provides a file management apparatus. Referring to fig. 9, fig. 9 is a schematic structural diagram of an embodiment of a document management apparatus provided in the present application.
Specifically, the file management apparatus 90 may include: an acquisition module 91, a splitting module 92 and a storage module 93.
The obtaining module 91 is configured to obtain a file size of the data file and a remaining storage space of the plurality of storage partitions.
The splitting module 92 is configured to split the data file into a plurality of subfiles according to a descending order of the sizes of the remaining storage spaces of the plurality of storage partitions if the file size of the data file is greater than the remaining storage space of each storage partition and less than the sum of the remaining storage spaces of all storage partitions.
The storage module 93 is configured to store the plurality of subfiles in corresponding storage partitions according to a file size of each subfile.
In one embodiment of the present application, each module in the file management apparatus 90 shown in fig. 9 may be separately or completely combined into one or several units, or some (some) of the units may be further split into a plurality of sub-units with smaller functions, which may implement the same operation without affecting the implementation of the technical effects of the embodiments of the present application. The above modules are divided based on logic functions, and in practical applications, the functions of one module may be implemented by a plurality of units, or the functions of a plurality of modules may be implemented by one unit. In other embodiments of the present application, the file management apparatus 90 may also include other units, and in practical applications, these functions may also be implemented with assistance by other units, and may be implemented by cooperation of multiple units.
The method is applied to the file management device. Referring specifically to fig. 10, fig. 10 is a schematic structural diagram of an embodiment of a file management apparatus provided in the present application, where the file management apparatus 100 includes a processor 110 and a memory 120. The memory 120 stores therein a computer program, and the processor 110 is configured to execute the computer program to implement the file management method described above.
The processor 110 may be an integrated circuit chip with signal processing capability. Processor 110 may also be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
For the file management method of the above embodiment, which may be presented in the form of a computer program, the present application proposes a computer storage medium carrying the computer program, please refer to fig. 11, fig. 11 is a schematic structural diagram of an embodiment of the computer storage medium provided in the present application, and the computer storage medium 200 of the present embodiment includes a computer program 210, which may be executed to implement the file management method described above.
The computer storage medium 200 of this embodiment may be a medium that may store program instructions, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disc, or may be a server that stores the program instructions, and the server may send the stored program instructions to other devices for execution, or may also self-execute the stored program instructions.
In addition, the above-described functions, if implemented in the form of software functions and sold or used as a separate product, may be stored in a mobile terminal-readable storage medium, that is, the present application also provides a storage device storing program data that can be executed to implement the method of the above-described embodiment, the storage device may be, for example, a U-disk, an optical disk, a server, or the like. That is, the present application may be embodied in a software product that includes instructions for causing a smart terminal to perform all or part of the steps of the methods described in the various embodiments.
In the description of the present application, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "plurality" is at least two, such as two, three, etc., unless explicitly defined otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and further implementations are included within the scope of the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present application.
Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., may be considered as a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device (which can be a personal computer, server, network device, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions). For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer readable medium may even be paper or other suitable medium on which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
The foregoing description is only of embodiments of the present application, and is not intended to limit the scope of the patent application, and all equivalent structures or equivalent processes using the descriptions and the contents of the present application or other related technical fields are included in the scope of the patent application.

Claims (13)

1. A file management method, characterized in that the file management method comprises:
acquiring the file size of a data file and the residual storage space of a plurality of storage partitions;
if the file size of the data file is larger than the residual storage space of each storage partition and smaller than the sum of the residual storage spaces of all the storage partitions, splitting the data file into a plurality of subfiles according to the descending order of the sizes of the residual storage spaces of the storage partitions;
and storing the plurality of subfiles in corresponding storage partitions according to the file size of each subfile.
2. The file management method according to claim 1, wherein said file management method further comprises:
if the data file is detected to be required to be displayed, all the subfiles are opened from the storage partition;
Reading the offset position of each subfile in the data file from each subfile;
and restoring all the subfiles according to the offset positions to display the data file.
3. The file management method according to claim 2, wherein after said restoring all said subfiles according to said offset positions to display said data file, said file management method further comprises:
acquiring a position identifier of a command pointer in the data file before splitting the data file into a plurality of subfiles;
the command pointer is displayed in the data file based on the location identification.
4. The file management method according to claim 2, wherein said file management method further comprises:
if the writing of the new data in the data file is detected, acquiring the writing position of the new data in the data file;
and storing the newly added data in a storage partition based on the writing position and the storage partitions of the plurality of subfiles.
5. The file management method according to claim 4, wherein said storing the newly added data in a memory partition based on the writing location and the memory partition of the plurality of subfiles comprises:
Determining a target sub-file where the writing position is located and a first storage partition where the target sub-file is located;
if the first storage partition has residual storage space, storing the newly added data in the first storage partition;
and if the first storage partition has no residual storage space and the second storage partition has residual storage space, storing the newly added data in the second storage partition, wherein the second storage partition comprises other storage partitions storing the subfiles.
6. The file management method according to claim 5, wherein said file management method further comprises:
if the second storage partition has no residual storage space, and the third storage partition which does not store the subfiles has residual storage space;
selecting a target storage partition with the largest residual storage space from the third storage partition to store the newly-added data;
if the target storage partition has no remaining storage space and the newly added data which is not stored still exists, returning to the step, if the second storage partition has no remaining storage space and the third storage partition which does not store the subfiles has remaining storage space, until the newly added data is stored.
7. The file management method according to claim 2, wherein after said restoring all said subfiles by said offset position to display said data file, said file management method further comprises:
responding to an operation instruction for closing the data file, and acquiring the file sizes of all the subfiles stored in the storage partition;
if the idle partition with the zero file size of the subfiles is detected to exist in the storage partition, deleting the folders used for storing the subfiles in the idle partition.
8. The file management method according to claim 1, wherein said file management method further comprises:
determining a file order among all the subfiles based on offset positions of each subfile in the data file;
acquiring the file sizes and the residual storage spaces of all the subfiles of the storage partition;
and merging all the subfiles according to the file sequence, the file size and the residual storage space.
9. The method of claim 8, wherein said merging all of said subfiles in said file order, said file size, and said remaining storage space comprises:
If the remaining storage space of the N storage partition where the N sub-file in the file sequence is located is greater than or equal to the file size of the N+1st sub-file in the file sequence, storing the N+1st sub-file in the N storage partition, and updating the remaining storage space of the N storage partition, wherein N is a natural number greater than 1;
and if the updated residual storage space of the N storage partition is greater than or equal to the file size of the (N+2) th subfile in the file sequence, storing the (N+2) th subfile in the N storage partition, and updating the residual storage space of the N storage partition.
10. The file management method according to claim 9, wherein said file management method further comprises:
if the remaining storage space of the N storage partition where the N sub-file is located in the file sequence is smaller than the file size of the N+1th sub-file in the file sequence, comparing the remaining storage space of the N+1th storage partition where the N+1th sub-file is located with the file size of the N+2th sub-file;
if the remaining storage space of the (N+1) th storage partition where the (N+1) th subfile in the file sequence is located is larger than or equal to the file size of the (N+2) th subfile in the file sequence, storing the (N+2) th subfile in the (N+1) th storage partition, and updating the remaining storage space of the (N+1) th storage partition;
And if the updated residual storage space of the N+1th storage partition is larger than or equal to the file size of the N+3rd subfile in the file sequence, storing the N+3rd subfile in the N+1th storage partition, and updating the residual storage space of the N+1th storage partition.
11. The file management method according to claim 9, wherein said file management method further comprises:
if the updated residual storage space of the N storage partition is smaller than the file size of the N+2 sub-file in the file sequence, comparing the residual storage space of the N+2 storage partition where the N+2 sub-file is located with the file size of the N+3 sub-file;
and if the remaining storage space of the N+2 storage partition where the N+2 subfile in the file sequence is located is larger than or equal to the file size of the N+3 subfile in the file sequence, storing the N+3 subfile in the N+2 storage partition, and updating the remaining storage space of the N+2 storage partition.
12. A file management apparatus, characterized by comprising: a processor and a memory, the memory having stored therein a computer program for executing the computer program to implement the method of any of claims 1 to 11.
13. A computer readable storage medium having stored thereon program instructions, which when executed by a processor, implement the method of any of claims 1 to 11.
CN202310089413.0A 2023-01-16 2023-01-16 File management method, device and storage medium Pending CN116107510A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310089413.0A CN116107510A (en) 2023-01-16 2023-01-16 File management method, device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310089413.0A CN116107510A (en) 2023-01-16 2023-01-16 File management method, device and storage medium

Publications (1)

Publication Number Publication Date
CN116107510A true CN116107510A (en) 2023-05-12

Family

ID=86253802

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310089413.0A Pending CN116107510A (en) 2023-01-16 2023-01-16 File management method, device and storage medium

Country Status (1)

Country Link
CN (1) CN116107510A (en)

Similar Documents

Publication Publication Date Title
US7809779B2 (en) Method of creating symbolic link capable of being compatible with file system, and method and apparatus for accessing file or directory by using symbolic link
US8499013B2 (en) FAT directory structure for use in transaction safe file system
US9563375B2 (en) Method for storing metadata of log-structured file system for flash memory
US11010104B2 (en) Optimized tape drive unmounting
US7836105B2 (en) Converting file-systems that organize and store data for computing systems
US20120084272A1 (en) File system support for inert files
US8332584B2 (en) Method of combining and managing file systems for memory space and a computer system
US11221989B2 (en) Tape image reclaim in hierarchical storage systems
CN109804359A (en) For the system and method by write back data to storage equipment
US20170168735A1 (en) Reducing time to read many files from tape
JP5962140B2 (en) Program, control method, control apparatus and system
US8589454B2 (en) Computer data file merging based on file metadata
US10114579B2 (en) Data migration tool with intermediate incremental copies
US10409693B1 (en) Object storage in stripe file systems
JPWO2007099636A1 (en) File system migration method, file system migration program, and file system migration apparatus
EP2669806A1 (en) Storage system
CN103177019B (en) Usb storage device and driving method thereof
US10831624B2 (en) Synchronizing data writes
WO2017172377A1 (en) File system support for file-level ghosting
CN116107510A (en) File management method, device and storage medium
EP2216721A1 (en) Data storage system and data storage program
KR101474285B1 (en) Fat file system and log data storage method of the same
US11495262B1 (en) Duplexing data from multiple file systems onto a shared tape
WO2023179529A1 (en) Linear tape file system unoptimized read detection
US11762603B2 (en) Storing modified or unmodified portions of a file based on tape loading

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination