基于OH中集成的三方开源工具的能力，实现对磁盘设备的识别、挂载、分区、格式化、检查和修复等相关能力。

文件	最后提交记录	最后更新时间
common	补充光驱刻录相关错误码和对应UT Co-Authored-By: Agent Signed-off-by: chenyu_code <chenyu454@h-partners.com>	10 天前
etc	update: 更新文件 disk_config Signed-off-by: zhonglufu <zhonglufu@h-partners.com>	2 个月前
figures	优化readme提示 Co-authored-by: Agent Signed-off-by: 宁竞莜 <ningjingyou@huawei.com>	2 个月前
interfaces	!109 merge fix/signed-bitwise-cdrom into master 优化 disk_manager 两处健壮性处理 Created-by: huni-li Commit-by: hunili Merged-by: openharmony_ci Description: Description: 优化 disk_manager 两处处理： 1. services/disk_manager/src/disk/uevent_bootstrap.cpp：QueryCdromState 中 status 为 int32_t，位运算前使用 static_cast<uint32_t> 转换，消除告警，逻辑行为不变。 2. interfaces/innerkits/src/volume_external.cpp：VolumeExternal::Unmarshalling 对 VolumeCore::Unmarshalling 返回值增加校验并记录日志，提升反序列化路径的健壮性；同时调整 Unmarshalling 与 Marshalling 的函数顺序。 Issue number: https://gitcode.com/openharmony/filemanagement_disk_manager/issues/108 Test & Result: - uevent_bootstrap.cpp：static_cast 转换不改变控制流，无新增分支，编译回归通过。 - volume_external.cpp：新增分支对应路径无法稳定触发单测覆盖，正常反序列化路径编译通过。 CodeCheck: <table> <tr> <th>类型</th><th>自检项</th><th>自检结果</th> </tr> <tr> <td rowspan="2">多线程相关</td><td>在类的成员变量中定义了vector/map/list等容器类型，且在多个成员函数中有操作时，需要加锁保护</td><td>自检结果：pass</td> </tr> <tr> <td>定义全局变量，在多个函数中都有操作时，需要加锁保护</td><td>自检结果：pass</td> </tr> <tr> <td rowspan="4">内存相关</td><td>调用外部接口时，确认是否对返回值做了判断，尤其外部接口返回了nullptr的情况，避免进程崩溃</td><td>自检结果：pass（本PR已增加 VolumeCore::Unmarshalling 返回值校验）</td> </tr> <tr> <td>调用安全函数时，如memcpy_s等，是否检查其返回值</td><td>自检结果：pass</td> </tr> <tr> <td>检查函数中是否涉及了内存或资源申请（如文件句柄），注意每个异常退出流程，是否都已经将资源释放（推荐使用RAII）</td><td>自检结果：pass（使用 unique_ptr 管理对象生命周期）</td> </tr> <tr> <td>隐式内存分配场景：realpath、ReadParcelable序列化、cJSON相关函数时等，需主动释放或使用智能指针</td><td>自检结果：pass</td> </tr> <tr> <td rowspan="4">校验外部输入</td><td>使用nlohmann:json解析外部输入时，需判断参数类型是否符合预期</td><td>自检结果：pass</td> </tr> <tr> <td>所有外部输入均不可信，需判断外部输入是否直接作为内存分配的大小，数组下标、循环条件、SQL查询等</td><td>自检结果：pass</td> </tr> <tr> <td>外部输入的路径不可信，需使用realpath做标准化处理，并判断路径的合法性</td><td>自检结果：pass</td> </tr> <tr> <td>外部输入包括对外提供的接口，IPC的proxy/stub接口，序列化/反序列化接口等</td><td>自检结果：pass（Unmarshalling 为反序列化接口，已增加返回值校验）</td> </tr> <tr> <td rowspan="2">数学运算</td><td>代码中是否混合了加减乘除等运算，需检查是否可能导致整数溢出或符号翻转</td><td>自检结果：pass</td> </tr> <tr> <td>需检查代码是否有高精度数字转换为低精度的操作，如果必须，建议使用C++安全类型转换接口</td><td>自检结果：pass（int32_t→uint32_t 同宽度，static_cast 安全）</td> </tr> <tr> <td rowspan="1">秘钥相关</td><td>如变量临时保存了口令、秘钥等，需要在使用完成后及时清空（内存memset掉）</td><td>自检结果：pass</td> </tr> <tr> <td rowspan="2">权限相关</td><td>作为系统服务对外提供了接口，是否做了权限保护和校验（如需要），只允许申请了权限的应用访问</td><td>自检结果：pass</td> </tr> <tr> <td>内核对外提供了设备节点，是否做了权限保护，只允许特定的系统服务访问</td><td>自检结果：pass</td> </tr> <tr> <td rowspan="3">内核操作</td><td>如有mmap操作，并使用remap_pfn_range进行地址映射时，校验起始地址是否是用户态输入且没有做合法性校验</td><td>自检结果：pass</td> </tr> <tr> <td>是否有copy_from_user，并对外部输入的数据做了长度校验，以防止缓冲区溢出</td><td>自检结果：pass</td> </tr> <tr> <td>是否有使用copy_to_user，并在返回到用户态时，对数据做了完整初始化，或使用memset清空后再赋值</td><td>自检结果：pass</td> </tr> </table> See merge request: openharmony/filemanagement_disk_manager!109	1 天前
sa_profile	修改diskmanager动态名，增加三接口权限校验 Signed-off-by: zhonglufu <zhonglufu@h-partners.com>	1 个月前
services	!138 merge master into master 更改change逻辑 Created-by: sunxiaoqianghappy Commit-by: s30051537 Merged-by: openharmony_ci Description: ### 一、内容说明（相关的Issue） https://gitcode.com/openharmony/filemanagement_disk_manager/issues/102 ### 二、建议测试周期和提测地址建议测试完成时间：xxxx.xx.xx 投产上线时间：xxxx.xx.xx 提测地址：CI环境/压测环境测试账号： ### 三、变更内容 * 3.1 关联PR列表 * 3.2 数据库和部署说明 1. 常规更新 2. 重启unicorn 3. 重启sidekiq 4. 迁移任务：是否有迁移任务，没有写 "无" 5. rake脚本：`bundle exec xxx RAILS_ENV = production`；没有写 "无" * 3.4 其他技术优化内容（做了什么，变更了什么） - 重构了 xxxx 代码 - xxxx 算法优化 * 3.5 废弃通知（什么字段、方法弃用？） * 3.6 后向不兼容变更（是否有无法向后兼容的变更？） ### 四、研发自测点（自测哪些？冒烟用例全部自测？）自测测试结论： ### 五、测试关注点（需要提醒QA重点关注的、可能会忽略的地方）检查点： \| 需求名称 \| 是否影响xx公共模块 \| 是否需要xx功能 \| 需求升级是否依赖其他子产品 \| \|------\|------------\|----------\|---------------\| \| xxx \| 否 \| 需要 \| 不需要 \| \| \| \| \| \| 接口测试：性能测试：并发测试：其他： See merge request: openharmony/filemanagement_disk_manager!138	6 小时前
test	!138 merge master into master 更改change逻辑 Created-by: sunxiaoqianghappy Commit-by: s30051537 Merged-by: openharmony_ci Description: ### 一、内容说明（相关的Issue） https://gitcode.com/openharmony/filemanagement_disk_manager/issues/102 ### 二、建议测试周期和提测地址建议测试完成时间：xxxx.xx.xx 投产上线时间：xxxx.xx.xx 提测地址：CI环境/压测环境测试账号： ### 三、变更内容 * 3.1 关联PR列表 * 3.2 数据库和部署说明 1. 常规更新 2. 重启unicorn 3. 重启sidekiq 4. 迁移任务：是否有迁移任务，没有写 "无" 5. rake脚本：`bundle exec xxx RAILS_ENV = production`；没有写 "无" * 3.4 其他技术优化内容（做了什么，变更了什么） - 重构了 xxxx 代码 - xxxx 算法优化 * 3.5 废弃通知（什么字段、方法弃用？） * 3.6 后向不兼容变更（是否有无法向后兼容的变更？） ### 四、研发自测点（自测哪些？冒烟用例全部自测？）自测测试结论： ### 五、测试关注点（需要提醒QA重点关注的、可能会忽略的地方）检查点： \| 需求名称 \| 是否影响xx公共模块 \| 是否需要xx功能 \| 需求升级是否依赖其他子产品 \| \|------\|------------\|----------\|---------------\| \| xxx \| 否 \| 需要 \| 不需要 \| \| \| \| \| \| 接口测试：性能测试：并发测试：其他： See merge request: openharmony/filemanagement_disk_manager!138	6 小时前
utils	fix:code Signed-off-by: 2301_76815458 <zhouaoteng@h-partners.com>	12 天前
.clang-format	优化文本描述 Signed-off-by: 宁竞莜 <ningjingyou@huawei.com>	2 个月前
BUILD.gn	修改diskmanager动态名，增加三接口权限校验 Signed-off-by: zhonglufu <zhonglufu@h-partners.com>	1 个月前
LICENSE	修复蓝区告警 Signed-off-by: zhonglufu <zhonglufu@h-partners.com>	1 个月前
OAT.xml	修复蓝区告警 Signed-off-by: zhonglufu <zhonglufu@h-partners.com>	1 个月前
README.md	优化readme提示 Co-authored-by: Agent Signed-off-by: 宁竞莜 <ningjingyou@huawei.com>	2 个月前
README_zh.md	优化readme提示 Co-authored-by: Agent Signed-off-by: 宁竞莜 <ningjingyou@huawei.com>	2 个月前
bundle.json	fix:code Signed-off-by: 2301_76815458 <zhouaoteng@h-partners.com>	12 天前
disk_manager.gni	DVR独立卷宗需求 Change-Id: I81a1a8f1f550f7db40c7124dd814091bb75be200 Signed-off-by: chenkang_jeff <chenkang45@huawei.com>	1 个月前

磁盘管理

磁盘管理概述

磁盘管理是OpenHarmony文件管理子系统中的磁盘管理部件。本部件基于OpenHarmony已集成的开源三方磁盘工具（例如gptfdisk、f2fs-tools等），负责磁盘与卷的识别、挂载与卸载、分区、检查、修复、格式化及相关事件处理。

系统架构

图1 OpenHarmony磁盘管理架构

磁盘管理架构说明

如图所示，系统由下至上分为应用层、框架层、系统服务层与内核层。

应用层
- 文件管理：面向文件与卷场景发起卷管理请求
- 系统设置：面向设备维护场景发起磁盘与分区管理请求
框架层
- Core File Kit：对上提供统一接口，并将请求转发至系统服务
系统服务层
- 磁盘管理服务：核心编排模块，负责状态管理、策略控制及对外能力呈现
- 磁盘查询：聚合磁盘与分区信息及状态
- 磁盘分区：执行分区创建、调整与删除
- 磁盘检查：执行文件系统检查
- 挂载卸载：执行卷挂载、卸载及状态切换
- 格式化：执行文件系统格式化
- 检查修复：执行文件系统修复
- 存储管理服务：承接高权限操作，与底层能力交互并回传结果
内核层
- 磁盘操作工具：提供分区、格式化、检查、修复等底层执行能力
- 内核文件系统：提供磁盘信息查询及状态变化上报

调用关系如下：文件管理与系统设置通过Core File Kit进入磁盘管理服务。磁盘管理服务通过进程间通信（Inter-Process Communication，IPC）协同存储管理服务，由内核层完成实际磁盘操作并回传状态。

目录结构

.
├── interfaces/                  # 对外接口层（IDL、innerkits、JS）
│   ├── innerkits/
│   └── kits/
├── services/disk_manager/       # SystemAbility（SA）服务实现（Provider、业务管理、daemon适配）
├── sa_profile/                  # SystemAbility配置与进程配置
├── common/                      # 通用错误码与基础定义
├── etc/                         # 业务配置信息
├── figures/                     # 服务介绍图
├── utils/                       # 日志与通用工具
└── test/                        # 单元测试与模糊测试

磁盘管理能力

磁盘与分区事件处理
卷信息查询
卷挂载与卸载、格式化、检查及修复

构建与集成

磁盘管理以系统服务部件形式纳入OpenHarmony文件管理（filemanagement）子系统，随系统镜像编译与部署。

源码落位：将本仓置于OpenHarmony源码树中的约定路径（路径定义见仓内bundle.json，示例路径为foundation/filemanagement/disk_manager）。与主干目录结构对齐后参与全量构建。
产品集成：在产品或芯片方案工程中，通过部件依赖（deps/部件列表）引入disk_manager构建目标。具体依赖写法以所属发行版或产品工程的部件集成规范为准。

磁盘管理开发指导

磁盘管理应用侧开发流程

下文面向在已集成本部件的系统镜像上开发、且需要使用卷与磁盘管理能力的应用开发者。

在ArkTS中通过Core File Kit导入接口（示例：import { volumeManager } from '@kit.CoreFileKit';）。若需在C++侧调用能力，按工程规范选用innerkits。若使用Taihe等链路，以工程模板为准。
@ohos.file.volumeManager为系统接口，仅系统应用可调用。在module.json5等配置中声明应用类型，并申请与各接口匹配的ohos.permission（例如卷查询常用STORAGE_MANAGER，挂载与卸载常用MOUNT_UNMOUNT_MANAGER，格式化与分区常用MOUNT_FORMAT_MANAGER。权限与接口的对应关系以官方文档为准）。
使用卷ID（示例：vol-{主设备号}-{次设备号}）或UUID，调用getAllVolumes、getVolumeById、getVolumeByUuid、mount、unmount、format、partition、setVolumeDescription等接口。遵守各接口对文件系统类型、卷状态等前置条件（例如部分操作仅在卸载态下可用），并参考文档给出的错误码。
查阅下文API参考中的@ohos.file.volumeManager（系统接口）及Core File Kit总览，获取接口说明、参数、错误码与示例。

API参考

上述文档给出磁盘管理相关接口的定义、参数与错误码说明。系统应用在具备相应磁盘能力的设备上，可据此完成设备识别以及卷的挂载、卸载、分区、检查、修复与格式化等操作。

filemanagement_disk_manager:基于 OpenHarmony 的磁盘管理工具项目