File address management methods, terminal devices and storage media

Abstract

This application relates to the field of address management and discloses a file address management method, terminal device, and storage medium. The file address management method, terminal device, and storage medium of this application determine the partition type to which the target file belongs based on the target file's attribute information, obtain the logical block address of the partition on the physical storage device, construct a data structure to store the logical block address, forming physical layout information, and then accurately obtain the physical storage location of the target file from the physical layout information according to the partition type. The file address management method of this application can not only effectively obtain the file storage location of ordinary data partitions in the Android system, but also cope with the file access needs of read-only partitions and protected partitions in high-security scenarios, significantly improving the efficiency and accuracy of file storage location acquisition, meeting the file location needs in different scenarios, and ensuring the accuracy and reliability of file access.

Description

Technical Field

[0001] This application relates to the field of address management technology, and in particular to a file address management method, terminal device and storage medium. Background Technology

[0002] In the current architecture of the Android platform, file storage and access mechanisms primarily rely on file system and block device management strategies. However, in practical applications, especially in certain specific scenarios, obtaining the start and end logical block addresses (LBAs) of files faces numerous challenges. Most existing file systems encapsulate the storage location of files, making it difficult for ordinary application layers to directly obtain the logical block addresses of files on physical storage devices. This situation is particularly challenging in scenarios requiring precise control over storage areas, such as data recovery and file tamper prevention.

[0003] The management of the file system and the underlying storage hardware is typically decoupled. While this design improves system flexibility and maintainability, it also introduces new problems. Higher-level file system calls cannot directly access or control the LBA information of the underlying storage device, which undoubtedly limits developers' ability to manage storage with fine precision. In Android systems, due to their specific optimizations for mobile devices, device mapping technologies, such as dm-verity, are widely used. These technologies aim to enhance system security and integrity, but they also further abstract and hide access to the physical storage of files, burying the actual physical LBA address of the file deep beneath a more complex mapping layer, making it difficult to obtain directly.

[0004] Therefore, how to obtain the physical location of a file on the Android system has become an important problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, embodiments of this application provide a file address management method, terminal device, and storage medium, which can effectively solve the problems of difficulty, complexity, low efficiency, and low accuracy in obtaining file addresses on the Android platform.

[0006] In a first aspect, embodiments of this application provide a file address management method, including:

[0007] Based on the attribute information of the target file, determine the partition type to which the target file belongs;

[0008] Based on the partition type, obtain the logical block address of the partition to which the target file belongs on the physical storage device;

[0009] Construct a data structure to store the logical block address of the partition to which the target file belongs on the physical storage device into the data structure to form physical layout information;

[0010] Based on the partition type, the logical block address of the target file on the physical storage device is obtained from the physical layout information.

[0011] In some embodiments, determining the partition type to which the target file belongs based on the target file's attribute information includes:

[0012] Based on the attribute information of the target file, obtain the device number of the block device to which the target file belongs;

[0013] Based on the device number, determine the path information corresponding to the block device;

[0014] Based on the path information corresponding to the block device, the partition type to which the target file belongs is obtained.

[0015] In some embodiments, obtaining the partition type to which the target file belongs based on the path information corresponding to the block device includes:

[0016] When the path information of the block device contains the first field, the partition type to which the target file belongs is determined to be a physical partition;

[0017] When the path information of the block device contains a second field, the partition type to which the target file belongs is determined to be a logical partition.

[0018] In some embodiments, when the path information of the block device includes a second field, the method further includes:

[0019] When the path information of the logical partition contains one and only one of the second fields, the partition is determined to be a logical partition with a single mapping.

[0020] When the path information of the logical partition contains multiple of the second fields, the partition is determined to be a logical partition with secondary mapping.

[0021] In some embodiments, obtaining the logical block address of the partition to which the target file belongs on the physical storage device according to the partition type includes:

[0022] When the partition type to which the target file belongs is the physical partition, the corresponding path information is read according to the device number of the block device to which the target file belongs, and the start logical block address and end logical block address of the physical partition are obtained.

[0023] When the partition type to which the target file belongs is the logical partition, the device path of the corresponding logical partition is determined according to the device number of the block device to which the target file belongs, the mapping relationship of the device is resolved according to the device path, and the logical block address of the partition to which the target file belongs is obtained according to the mapping relationship.

[0024] In some embodiments, obtaining the logical block address of the partition to which the file belongs based on the mapping relationship includes:

[0025] When the partition type is a logical partition with one-time mapping, the corresponding logical partition device path is determined according to the device number of the file; the device path of the physical partition is read according to the device path; the corresponding node information is determined according to the device path of the physical partition to obtain the start logical block address and end logical block address of the physical partition.

[0026] When the partition type is a secondary mapping logical partition, the corresponding logical partition device path is determined according to the device number of the target file; the device path of the upper-level logical partition is read according to the device path of the secondary mapping logical partition; the device path of the physical partition is read according to the device path of the upper-level logical partition; the corresponding node information is determined according to the device path of the physical partition to obtain the start logical block address and end logical block address of the physical partition.

[0027] In some embodiments, constructing a data structure to store the logical block address of the partition to which the target file belongs on the physical storage device into the data structure to form physical layout information includes:

[0028] Define the data structure to store the logical block address of the partition to which the target file belongs on the physical storage device;

[0029] The preset interface is called repeatedly to obtain all logical block addresses of the partition to which the target file belongs on the physical storage device, and the logical block address returned by each call is stored in the data structure to form the physical layout information.

[0030] In some embodiments, obtaining the logical block address of the target file on the physical storage device from the physical layout information according to the partition type includes:

[0031] When the partition type is a physical partition, the logical block address of the target file on the physical storage device is calculated based on the start and end logical block addresses of the physical partition and the physical layout information.

[0032] When the partition type is a logical partition with one-time mapping, the logical block address of the target file on the physical storage device is calculated in segments based on the starting logical block address and ending logical block address of the physical partition, the mapping table, and the physical layout information.

[0033] When the partition type is a logical partition with secondary mapping and the logical partition is a normal proportional mapping, the logical block address of the target file on the physical storage device is calculated based on the starting logical block address and ending logical block address of the physical partition, using the mapping table and the physical layout information.

[0034] In some embodiments, when the partition type is a physical partition, the logical block address of the target file on the physical storage device is calculated using the following formula:

[0035]

[0036] in, This represents the nth logical block address pair of the target file in the physical storage device. This indicates the starting logical block address of the physical partition where the target file is located. Relative to the starting address The offset, + This indicates the logical block address of the target file on the physical storage device.

[0037] In some embodiments, when the partition type is a once-mapped logical partition, the logical block address of the target file on the physical storage device is calculated using the following formula:

[0038] The logical block address of each mapped region in the physical partition is calculated using the following formula:

[0039]

[0040] in, This represents the m-th dm-th mapping segment region; This represents the logical block address range of the m-th mapped region within the physical partition; This represents the mapping offset of the m-th segment within the logical partition; This represents the logical block address range of the m-th mapping segment region within the physical partition; This indicates the range of corresponding logical block addresses for the same mapped segment region within the logical partition.

[0041] The logical block address of the target file on the physical storage device is calculated using the following formula:

[0042]

[0043] in, This represents a region of the target file on the physical partition, namely the address range of the nth logical block; This indicates the starting logical block address of the physical partition where the target file is located; ... This indicates the starting offset of the mapping of each dm mapping segment region within the physical partition; ... This indicates the mapping offset of the corresponding mapping segment region within the logical partition; This indicates the starting logical block address of the first DM mapping segment region in the physical partition, corresponding to the logical interval [ , ]; ... This indicates the offset of the target file within the logical partition.

[0044] Secondly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the file address management method of the first aspect described above.

[0045] Thirdly, embodiments of this application provide a computer-readable storage medium, wherein when the computer program is executed on a processor, it implements the file address management method of the first aspect described above.

[0046] The embodiments of this application have the following beneficial effects:

[0047] This application's file address management method, terminal device, and storage medium determine the partition type of the target file based on its attribute information, obtain the logical block address of the partition containing the target file on the physical storage device based on the partition type, and construct a data structure to store this information, thereby forming a physical layout. Based on the partition type, the logical block address of the target file can be accurately obtained from the physical layout information. This method can not only effectively obtain the file storage location of ordinary data partitions in the Android system, but also handle read-only partitions and protected partitions in high-security scenarios, especially suitable for secondary mapping partitions involving protection mechanisms such as dm-verity. This application significantly improves the efficiency and accuracy of file storage location acquisition, ensures the accuracy and reliability of file access, and meets the file location needs in various scenarios. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 A flowchart of a file address management method according to an embodiment of this application is shown;

[0050] Figure 2 This illustration shows a schematic diagram of the physical partition to which a file belongs in a file address management method according to an embodiment of this application;

[0051] Figure 3 This illustration shows a schematic diagram of the logical partition to which a file belongs in a file address management method according to an embodiment of this application;

[0052] Figure 4 This illustration shows another schematic diagram of the logical partition to which a file belongs in a file address management method according to an embodiment of this application;

[0053] Figure 5 This illustration shows a schematic diagram of the file distribution within a physical partition in a file address management method according to an embodiment of this application;

[0054] Figure 6 This illustration shows another distribution diagram of files within a physical partition in a file address management method according to an embodiment of this application. Detailed Implementation

[0055] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0056] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0057] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0058] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0059] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0060] Considering the difficulties, complexity, inefficiency, and low accuracy of obtaining file addresses on the Android platform, this application proposes a file address management method. Specifically, this method determines the partition type of the target file based on its attribute information, obtains the logical block address of the partition containing the target file on the physical storage device based on the partition type, constructs a data structure to store this information, thus forming a physical layout. Furthermore, the address of the target file can be accurately obtained from the physical layout information based on the partition type. This method not only effectively obtains the file storage location of ordinary data partitions in the Android system but also handles read-only partitions and protected partitions in high-security scenarios. It is particularly suitable for secondary mapping partitions involving protection mechanisms such as dm-verity, where dm-verity is a submodule of Device Mapper used to verify the integrity of block device data. It significantly improves the efficiency and accuracy of file storage location acquisition, ensuring the accuracy and reliability of file access. It can accurately obtain the logical block address of files in partitions that have not been mapped by Device Mapper (dm), and supports the logical block address of files in partitions that have been mapped by dm, meeting the file location needs in various scenarios and improving the efficiency and security of file access.

[0061] Figure 1 A flowchart illustrating a file address management method according to an embodiment of this application is shown. Exemplarily, this file address management method is based on the Android platform and includes the following steps:

[0062] Step S100: Determine the partition type to which the target file belongs based on the attribute information of the target file.

[0063] For example, attribute information refers to metadata associated with a file. Attribute information describes the basic characteristics of the file and may include the following: for example, file path, device ID, inode, file size, etc. The device ID represents the disk device where the file resides. The device ID is a unique identifier indicating the storage device or partition where the file is located, and it is typically composed of a major device number and a minor device number.

[0064] Partition type refers to the type of partition where the file system resides. For example, (1) Normal partition (ext4, NTFS, FAT32, etc. file systems): A partition created directly on a physical hard disk or virtual storage device without any additional mapping mechanism. File system operations are directly mapped to the blocks of the underlying storage device. (2) Device Mapper (dm) device: Used to create virtual devices. The dm device itself is not directly mapped to physical storage, but rather the logical device is mapped to the physical device through a mapping layer. When using a dm device, data is usually not stored directly in the physical partition, but in a virtual logical partition. (3) dm-verity device: dm-verity is a special type of device based on Device Mapper. It is used to provide read-only, tamper-proof data verification and validation functions for storage devices. The goal of dm-verity is to ensure data integrity. It is usually used in encrypted disks or systems that require data integrity. Furthermore, dm-verity is a two-level mapping, that is, the file is first mapped to the virtual partition, and then mapped to the actual physical device.

[0065] In other words, based on the device number (st_dev) where the file is located, it can be determined whether the storage device where the file is located is a regular partition, a device that is virtually mapped through a Device Mapper (e.g., a dm device), or a device that uses dm-verity to provide integrity protection.

[0066] In an optional embodiment, step S100, determining the partition type to which the target file belongs based on the target file's attribute information, includes:

[0067] Step S110: Obtain the device number of the block device to which the target file belongs based on the attribute information of the target file.

[0068] As an example, the target file is opened using file operation functions provided by the operating system (e.g., `open()`), obtaining a file handle (i.e., a file descriptor). The file handle is an integer used to identify an opened file, which can be referenced in subsequent operations. The `fstat()` function is then called using the file handle to retrieve the file's attribute information. The `fstat()` function returns a `stat` structure containing the file's metadata. This structure contains several fields, the most important of which is:

[0069] Device number (st_dev): The device number of the device (partition) where the file is located (composed of major device number and minor device number).

[0070] inode number (st_ino): A unique identifier for a file, typically used for internal indexes in a file system.

[0071] File size (st_size): The file size in bytes.

[0072] File permissions, last access time, etc.

[0073] Extract the device number `st_dev` from the `stat` structure. The device number `st_dev` consists of a major device number and a minor device number. The major device number identifies the type of device, and the minor device number identifies a specific partition on that device. For example, a major device number of 8 and a minor device number of 1 in `st_dev` might represent the partition ` / dev / sda1`.

[0074] Step S120: Determine the path information corresponding to the block device based on the device number.

[0075] As an example, the path to the device containing the file is found based on the device number (st_dev). Block devices are typically located in the / dev / or / dev / block / directory. The specific path depends on the device type.

[0076] Step S130: Determine the partition type to which the file belongs based on the path information corresponding to the block device.

[0077] For example, if the block device path of a file belongs to a regular partition (e.g., sd, nvme, mmcblk), then the partition where the file resides is a regular physical partition, where the physical partition is a representation of the Android system partition table.

[0078] If the file's block device path belongs to a device of type dm (e.g., starting with dm-, dm-0, dm-1), then the partition containing the file is a Device Mapper device. If the block device path belongs to a dm-verity device (e.g., dm-verity, mapper / verity_device), then it belongs to a Level 2 mapped device, which is typically used to ensure the integrity of the file system.

[0079] That is, based on the device path, determine the device type (physical partition, DM device, DM-verity device, etc.) to determine the type of partition to which the file belongs.

[0080] In an optional embodiment, step S130, obtaining the partition type to which the target file belongs based on the path information corresponding to the block device, includes:

[0081] When the path information of a block device includes a first field, typically starting with sd, nvme, or mmcblk, it indicates that the partition to which the file belongs is a physical partition. A physical partition refers to a partition directly mapped to a hard disk or solid-state drive (SSD), without involving any logical volume management or virtualization layer. Figure 2 As shown.

[0082] When the path information of a block device contains a second field (usually starting with a field like / dev / dm- or / dev / mapper / ), it can be determined that the partition to which the file belongs is a logical partition. Logical partitions are virtual devices created through Device Mapper or similar virtualization mechanisms; common applications include LVM (Logical Volume Management), RAID, and encrypted partitions.

[0083] In one alternative embodiment, a single-mapped logical partition refers to a partition containing a file that is directly mapped to a physical storage device or partition, without intermediate virtualization or additional mapping layers. The path information for this type of partition contains only a second field (dm- or mapper / , etc.). That is, the device path is directly mapped to the virtual device of the physical storage device, without multiple layers of mapping, such as... Figure 3 As shown.

[0084] For example, dm-0: This path contains only one dm- field, which represents a logical partition of a single mapping.

[0085] A logical partition with secondary mapping refers to a partition containing a file that has undergone two layers of mapping. That is, a logical partition on the Device Mapper is further mapped to another virtual layer or physical device. The path information for this type of partition includes multiple second fields (e.g., dm- or mapper), indicating that the device path has passed through multiple mapping layers, thus forming secondary or multiple mappings. Figure 4 As shown.

[0086] For example, dm-0 and dm-1: If there are multiple dm-X fields in the device path, it means that the device has been mapped multiple times.

[0087] / dev / mapper / verity_device: This is a dm-verity device, representing a logical partition of a secondary mapping. It is worth noting that dm-verity type mapping is a full-scale mapping, that is, a mapping without offset.

[0088] Step S200: Based on the partition type, obtain the logical block address of the partition to which the target file belongs on the physical storage device.

[0089] As an example, partition type is an important attribute of the storage device where a file resides, determining how the file is stored on the disk. The method for determining the file's storage location also differs depending on the partition type.

[0090] For regular partitions (such as standard ext4 or NTFS), the file's location on the physical storage device can be calculated directly from the starting LBA of the partition where the file resides. The file's logical block address (LBA) plus the starting LBA of the partition gives the file's physical location on the disk.

[0091] For DM devices, the file's logical domain name (LBA) within the partition is calculated using a mapping table. First, the mapping relationship of the DM device needs to be resolved to obtain the file's relative LBA. Then, this logical partition is mapped to the actual physical partition, and the file's actual physical location is calculated by combining this with the starting LBA of the physical partition.

[0092] For dm-verity devices, since dm-verity is a read-only verification device, the file storage location may be a secondary mapping. First, the dm-verity mapping table needs to be parsed to obtain the logical block address (LBA) of the file on the dm-verity device. Then, the mapping relationship of its next-level device (usually a physical device) is parsed to finally obtain the LBA of the physical storage device.

[0093] In one embodiment, step S200, based on the partition type, obtains the logical block address of the partition to which the target file belongs on the physical storage device, including:

[0094] Step S210: When the partition type to which the file belongs is a physical partition, read the corresponding path information according to the device number of the block device to which the target file belongs, and obtain the starting logical block address and ending logical block address of the physical partition.

[0095] For example, when the partition to which the file belongs is a physical partition (i.e., the file is directly stored on a partition on a hard drive or other physical storage device), first, the corresponding device information path is found in the / sys / block / directory based on the device number of the partition to which the file belongs. For example, the path / sys / block / sdx / sdxy / start refers to the starting logical block address (LBA) of a partition (e.g., / dev / sdxy) on a storage device (e.g., / dev / sdx). The start node stores the starting LBA value of the partition, indicating the starting position of the partition on the physical disk.

[0096] In addition, the `ioctl` function can be used to obtain hard disk geometry information. `ioctl(fd, HDIO_GETGEO, &g)` is a system call interface used for device control and management. Here, `fd` is the file descriptor of the block device file, representing the hard disk device. `HDIO_GETGEO` is the command to retrieve hard disk geometry information, which returns the geometry information via the `ioctl` call. `&g` is a pointer to an `hd_geometry` structure, used to store the hard disk geometry information. `ioctl` fills this structure with the hard disk geometry information. `g` is a variable, specifically a declared and prepared variable of type `hd_geometry`. In particular, it also contains the starting LBA information of the partition where the target file is located.

[0097] In other words, when ioctl(fd, HDIO_GETGEO, &g) is called, the operating system accesses the hard disk device through fd and sends an HDIO_GETGEO request to the device. The hard disk device driver responds to this request and fills the hard disk's geometry information into the hd_geometry structure pointed to by g. This information includes the number of hard disk heads and the number of sectors per head, and is typically used to describe the physical structure of the hard disk.

[0098] Step S220: When the partition type to which the target file belongs is a logical partition, determine the device path of the corresponding logical partition according to the device number of the block device to which the target file belongs, parse the device mapping relationship according to the device path, and obtain the logical block address of the partition to which the file belongs according to the mapping relationship.

[0099] As an example, when the partition to which the file belongs is a logical partition (e.g., LVM, RAID, dm-verity, etc.), the device path of the logical partition where the file resides can be determined based on the file's device number. The device path is typically / dev / dm-X or / dev / mapper / lvm_volume, pointing to a virtual device created through a Device Mapper or similar mechanism. By resolving the device path, the mapping relationship of that device can be obtained, i.e., how the logical partition is mapped to the physical storage device. This mapping relationship is usually obtained through mapping tables, which provide the actual location of the file data on the physical device. Based on the mapping relationship, the logical block address (LBA) of the file within the logical partition can be obtained, representing the file's storage location within the logical partition.

[0100] In other words, for physical partitions, the partition path is obtained through the file's device number, and the start and end LBAs of that physical partition are directly obtained. For logical partitions, the logical partition path is determined through the device number, and the logical block address of the file within that partition is obtained after resolving the mapping relationship.

[0101] In an optional embodiment, when the partition to which the target file belongs is a once-mapped logical partition, the file data is stored in a logical partition mapped to the physical storage device via Device Mapper or similar virtualization technology. In this case, firstly, the corresponding logical partition device path is determined based on the file's device number, for example, / sys / block / dm-x / slaves / . Then, based on this device path, the device path of the physical partition sdxy is further resolved. Typically, this path points to the actual storage device. Next, the / sys / block / sdx / sdxy / start node value of the physical partition is obtained from the device path of the physical partition. This information contains the start and end logical block addresses of the partition on the physical storage device. Through these start and end LBAs, the storage range of the file within the physical partition can be determined, thereby locating the actual position of the file on the physical storage device.

[0102] When the target file belongs to a logical partition with two levels of mapping, the file data is stored on the logical partition through which the mapping takes place. First, the device path of the logical partition where the file resides is determined based on the file's device number, for example, / sys / block / dm-x / slaves / . By accessing this path, the physical partition block device to which the dm device is actually mapped can be found. The slaves directory contains the actual path to the mapped physical storage device.

[0103] Then, use ioctl(fd, HDIO_GETGEO, &g) to obtain the disk geometry information, or access the / sys / block / sdx / sdxy / start node, which stores the starting LBA values ​​of the partition. These values ​​represent the actual storage range of the file on the physical storage device. With this information, the file's location on the physical storage device can be accurately calculated.

[0104] Step S300: Construct a data structure and store the logical block address of the partition to which the target file belongs on the physical storage device into the data structure to form and use physical layout information.

[0105] As an example, a data structure is constructed to store the logical block address (LBA) of a file on the physical storage device and related information, and this information is organized into physical layout information. This data structure allows for efficient management and tracking of the file's storage location on the physical storage device, especially in cases involving logical partitions and multi-level mappings.

[0106] Specifically, by constructing data structures, the physical layout information of files is stored, namely the logical block address of the file in the physical storage device, and the storage information of the file in different mapping levels. In other words, by constructing data structures, file location and access can be supported, especially in complex storage architectures (e.g., logical partitions, virtual devices, multi-level mappings), ensuring that the physical storage location of files can be found quickly and accurately. Furthermore, as the storage structure changes, the data structures can be flexibly modified and updated to support more devices and partition types.

[0107] In one embodiment, step S300 involves constructing a data structure and storing the logical block address of the partition to which the target file belongs on the physical storage device into the data structure to form and use physical layout information, including:

[0108] Step S310: Define a data structure to store the logical block address of the partition to which the target file belongs on the physical storage device.

[0109] As an example, a data structure is defined to store the logical block addresses (LBAs) of a file on the physical storage device. These logical block addresses represent the location where the file data is stored on the physical storage device. The logical block address (LBA) is the specific location of the file data on the disk, typically represented as a start address and an end address. The data structure may be a linked list or an array used to store multiple physical intervals of the file, with the start and end LBAs of each interval stored in fields of the structure.

[0110] Step S320: Repeatedly call the preset interface to obtain all logical block addresses of the partition to which the target file belongs on the physical storage device, and store the logical block addresses returned by each call into the data structure to form physical layout information.

[0111] Use a predefined interface (e.g., `ioctl(fd, FS_IOC_FIEMAP, &fiemap)`) to obtain the logical block address of a file on the physical storage device. Here, `fd` is the file handle of the target file, and `fs` is a `struct fiemap` structure describing the physical block mapping of the file on the storage device. Since file data may be stored non-contiguously across multiple physical regions, the file mapping on the physical storage device may also be non-contiguous. Therefore, it is necessary to call `ioctl` multiple times to obtain the complete file mapping.

[0112] Each time the API is called, it returns the physical storage range of the file data. These ranges consist of multiple contiguous physical block segments. Specifically, the physical layout of the file `target_file` is n contiguous storage ranges within each segment:

[0113]

[0114] in, , … This refers to multiple mapped regions of a file within a partition. Due to the fragmented management of the file system, the data blocks of a file are scattered and stored in different blocks, thus forming such multiple mapped regions. The interval within curly braces represents the start and end LBAs of each mapped region relative to its respective partition, denoted by uppercase X; while the interval within square brackets represents the internal offset of the mapped region to the target file, denoted by lowercase x.

[0115] Each logical block address returned by an API call is stored in a previously defined data structure. This data structure gradually accumulates all LBA information, representing the file's physical layout on the disk. If the file data is distributed across multiple physical regions, these regions are stored one by one in the data structure. Typically, a linked list is used to store information about multiple consecutive physical regions. Once all logical block addresses are stored in the data structure, the file's physical layout information on the physical storage device is formed. This layout information can be used for subsequent operations, such as file location, defragmentation, and data recovery.

[0116] Step S400: Based on the partition type, obtain the logical block address of the target file on the physical storage device from the physical layout information.

[0117] For example, physical partitions: if the target file is located on a physical partition (e.g., / dev / block / sdxX), then the starting LBA of the partition is used ( ) and end LBA ( Combining the multi-segment distribution of the file in the physical layout information, the actual LBA of the file on the physical storage device is calculated by directly accumulating the segment offset values.

[0118] Logical partition of a single mapping: If the target file is located in the dm logical partition of a single mapping (e.g., / dev / block / dm-x), it is necessary to traverse the mapping area to which the file belongs, determine whether it is within the segment offset range of the dm mapping table, and calculate the file's physical LBA segment by segment using the formula.

[0119] Logical partitioning of secondary mapping: If the target file is located in the dm-verity logical partition of secondary mapping, then based on its offset-free mapping characteristic and the consistent mapping relationship between the parent and child devices, the segmented calculation method of primary mapping is reused. Combined with the consistency of the mapping relationship between the parent and child devices of dm, the physical LBA of the file is directly calculated using the same formula.

[0120] In one embodiment, step S400, obtaining the logical block address of the target file on the physical storage device from the physical layout information according to the partition type, includes:

[0121] Step S410: When the partition type is a physical partition, calculate the logical block address of the target file on the physical storage device based on the starting logical block address and ending logical block address of the physical partition, combined with the physical layout information.

[0122] For example, such as Figure 5 As shown, the mapped address of the physical disk corresponding to the physical partition sdxx to which the file belongs is set to [ , ], As the starting point of the partition, This is the partition endpoint, representing the address of the last logical block of the physical partition, i.e., the endpoint address, used to limit the upper bound of the following offset values. That is, [ , [] represents the complete LBA range of the physical partition to which the file belongs across the entire disk. Therefore, the actual distribution information of the target file on the physical disk is as follows:

[0123]

[0124] in, This represents the address range of the nth logical block in the physical storage device of the target file;

[0125] This indicates the starting logical block address of the physical partition where the target file is located, i.e., the starting address;

[0126] Relative to the starting address The offset;

[0127] + This indicates the logical block address of the target file on the physical storage device.

[0128] The distribution information of the target file on the physical disk is represented by logical block address pairs, each logical block address pair being determined by the starting logical block address. Add the corresponding offset Composition. For example, for This indicates the start and end addresses of the file in the first logical block address pair, i.e. and These formulas can be used to determine the specific storage location of a file on the physical disk, thereby enabling the correct reading and storage of the file.

[0129] Step S420: When the partition type is a logical partition with one-time mapping, the logical block address of the target file on the physical storage device is calculated in segments based on the starting and ending logical block addresses of the physical partition, the mapping table, and the physical layout information.

[0130] like Figure 6 As shown, when the partition is a logical partition mapped once, firstly, the starting LBA of the DM device when mapping the actual physical partition is obtained. Then, the mapping table of the DM device is obtained through the dmctl tool (or related source code tools). The starting LBA of the DM mapped physical partition is obtained through the mapping table. Assuming that the DM mapped physical partition has multiple segments, let's say it is divided into m segments, and the mapping LBA of each segment is:

[0131]

[0132] in, , … The DM partition actually maps to multiple segments of the physical partition, and each DM partition may also map to multiple segments of the physical partition. The intervals within the curly braces are... This is represented by the LBA range of each mapped region within the physical partition, indicated by the uppercase letter Y; while the area within square brackets... This represents the mapping offset within the dm partition, denoted by lowercase y; This is the LBA range of the mapped segment in the physical partition sdxx; The corresponding LBA intervals in the dm logical partitions are the same mapping segment; the two intervals correspond one-to-one.

[0133] The physical partition sdxx mapped by the dm device has an LBA range of [ ] within the entire physical disk. , ], where represents the starting logical block address (starting point) of the physical partition where the target file is located; represents the ending logical block address (ending point) of the physical partition. Based on the offset of the target file on the DM device and the above two offsets, the actual distribution on the physical disk is calculated: traversal ~ The mapping region of each segment above—whether it is within the dm mapping relative to the start and end LBA (interval within curly braces, uppercase X) of the partition to which it belongs. ~ Within the offset range (the interval within square brackets, lowercase y) of each DM partition segment, if the requirements are met, then use the start and end LBAs of each segment within the curly braces in the DM segment in the physical partition for calculation. The calculation formula is:

[0134]

[0135] in, This represents a segment of the target file's distribution on the physical partition, specifically the nth logical block address range (starting LBA, ending LBA).

[0136] Indicates the starting logical block address (starting point) of the physical partition where the target file is located;

[0137] ... Indicates the starting offset (relative) of each DM mapping segment in the physical partition. (the uppercase Y); that is, ... This indicates the segment Y that is contained within the brackets of the interval containing region A;

[0138] ... This indicates the starting offset of the mapping within the logical partition for the corresponding mapped segment;

[0139] in, , Specifically corresponds to the first mapping segment. The start and end LBA offsets in the physical partition, and the logical interval [ , Paired, subsequent { , }correspond[ +1, ],…,{ , }correspond[ -1+1, And so on; ... This indicates the offset of the target file within the logical partition.

[0140] Step S430: When the partition type is a logical partition with secondary mapping and the logical partition is a normal proportional mapping, the logical block address of the target file on the physical storage device is calculated based on the starting logical block address and ending logical block address of the physical partition, using the mapping table and physical layout information.

[0141] When the partition is a logical partition with a secondary mapping, the dm-verity type mapping belongs to the original proportional mapping, that is, the mapping without offset. The mapping state of the dm parent device is consistent with the mapping relationship of the child dm device (dm-verity device). Therefore, the method for calculating LBA is the same as when the partition is a logical partition with a primary mapping. See the explanation of step S420 above, which will not be repeated here.

[0142] The file address management method of this application can not only accurately obtain the LBA of files in partitions without DM mapping, but also supports obtaining the LBA of files in partitions with DM mapping. It is particularly suitable for secondary mapping partitions involving protection mechanisms such as DM-Verity. The file address management method of this application can efficiently locate the file storage location of ordinary data partitions in the Android system and meet the file access requirements in high-security scenarios (e.g., read-only partitions and protected partitions), effectively improving the efficiency and accuracy of file storage location acquisition and ensuring the accuracy and reliability of file access.

[0143] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the file address management method described above.

[0144] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0145] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0146] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0148] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0149] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a terminal device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0150] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A file address management method characterized by comprising: The method comprises: According to the attribute information of the target file, the device number of the block device to which the target file belongs is obtained; According to the device number, the path information corresponding to the block device is determined; When the path information contains a first field, it is determined that the partition type to which the target file belongs is a physical partition; when the path information contains a second field, it is determined that the partition type to which the target file belongs is a logical partition; wherein, when there is only one second field in the path information of the logical partition, it is determined that the partition is a one-time mapped logical partition; when there are multiple second fields in the path information of the logical partition, it is determined that the partition is a two-time mapped logical partition; According to the partition type, the logical block address of the partition to which the target file belongs on the physical storage device is obtained; A data structure is constructed to store the logical block address of the partition to which the target file belongs on the physical storage device in the data structure to form physical layout information; When the partition type is a physical partition, the starting logical block address and the ending logical block address of the physical partition are combined with the physical layout information to calculate the logical block address of the target file on the physical storage device; When the partition type is a one-time mapped logical partition, the starting logical block address and the ending logical block address of the physical partition are combined with the physical layout information based on a mapping table to calculate the logical block address of the target file on the physical storage device in segments; When the partition type is a two-time mapped logical partition and the logical partition is a primary proportional mapping, the starting logical block address and the ending logical block address of the physical partition are combined with the physical layout information using the mapping table to calculate the logical block address of the target file on the physical storage device.

2. The file address management method according to claim 1, characterized by, The method comprises: When the partition type to which the target file belongs is the physical partition, the corresponding path information is read according to the device number of the block device to which the target file belongs to obtain the starting logical block address and the ending logical block address of the physical partition; When the partition type to which the target file belongs is the logical partition, the device path of the corresponding logical partition is determined according to the device number of the block device to which the target file belongs, the mapping relationship of the device is parsed according to the device path, and the logical block address of the partition to which the target file belongs is obtained according to the mapping relationship.

3. The file address management method according to claim 2, characterized by, The method comprises: When the partition type is a one-time mapped logical partition, the corresponding logical partition device path is determined according to the device number of the file; the device path of the physical partition is read according to the device path; the corresponding node information is determined according to the device path of the physical partition to obtain the starting logical block address and the ending logical block address of the physical partition. When the partition type is the secondary mapping logical partition, according to the device number of the target file, the corresponding logical partition device path is determined; according to the device path of the secondary mapping logical partition, the device path of the upper logical partition is read, and according to the device path of the upper logical partition, the device path of the physical partition is read; according to the device path of the physical partition, the corresponding node information is determined to obtain the start logical block address and the end logical block address of the physical partition.

4. The file address management method of claim 1, wherein The data structure is constructed, and the logical block address of the partition to which the target file belongs on the physical storage device is stored in the data structure to form physical layout information, including: The data structure is defined to store the logical block address of the partition to which the target file belongs on the physical storage device. The preset interface is called in a loop to obtain all logical block addresses of the partition to which the target file belongs on the physical storage device, and the logical block address returned by each call is stored in the data structure to form the physical layout information.

5. The file address management method of claim 1, wherein, When the partition type is the physical partition, the logical block address of the target file on the physical storage device is calculated by the following formula: wherein, represents the n-th logical block address pair of the target file in the physical storage device; represents the start logical block address of the physical partition where the target file is located; represents the offset relative to the start address ; + represents the logical block address of the target file on the physical storage device.

6. The file address management method according to claim 5, characterized by, When the partition type is the primary mapping logical partition, the logical block address of the target file on the physical storage device is calculated by the following formula: The logical block address of each mapping region in the physical partition is calculated by the following formula: wherein, represents the mth dm mapping segment region; represents the logical block address range of the mth segment mapping region in the physical partition; represents the mapping offset of the mth segment within the logical partition; represents the logical block address range of the mth mapping segment region in the physical partition; represents the corresponding logical block address range of the same mapping segment region in the logical partition; The logical block address of the target file on the physical storage device is calculated by the following formula: wherein, represents a segment region of the target file on the physical partition, i.e. the nth segment logical block address interval; represents the starting logical block address of the physical partition where the target file is located; ... represents the mapping starting offset of each of the dm mapping segment regions in the physical partition; ... represents the mapping offset of the corresponding mapping segment region inside the logical partition; represents the starting logical block address of the first dm mapping segment region in the physical partition, corresponding to the logical interval[ , ]; ... represents the offset of the target file in the logical partition.

7. A terminal device, characterized by comprising: The terminal device includes a processor and a memory, the memory stores a computer program, and the processor is configured to execute the computer program to implement the file address management method of any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer program is stored in the memory, and when the computer program is executed on the processor, the file address management method according to any one of claims 1-6 is implemented.

Images