从删库到恢复：LRCGet文件删除逻辑深度剖析与安全重构方案

从删库到恢复：LRCGet文件删除逻辑深度剖析与安全重构方案

【免费下载链接】lrcget Utility for mass-downloading LRC synced lyrics for your offline music library. 项目地址: https://gitcode.com/gh_mirrors/lr/lrcget

引言：当删除操作变成数据灾难

在音乐管理工具LRCGet的日常使用中，用户可能会遇到一个隐藏的风险：文件删除操作异常。想象一下，当你尝试更新一首歌曲的歌词时，程序不仅删除了旧的LRC文件，还意外删除了你的音乐文件本身；或者当你切换歌词显示模式时，整个专辑的歌词文件被无提示地批量删除。这些并非危言耸听，而是LRCGet项目在文件删除逻辑中存在的真实隐患。

本文将深入分析LRCGet项目的文件删除机制，揭示其中的设计缺陷，并提供一套完整的重构方案。通过本文，你将能够：

• 理解文件删除逻辑中的错误处理机制
• 识别潜在的数据安全风险点
• 掌握安全删除操作的最佳实践
• 学会如何为关键操作添加用户确认机制
• 建立完善的操作日志系统

一、LRCGet文件删除逻辑现状分析

1.1 文件删除操作分布

通过对LRCGet源代码的全面审计，我们发现文件删除操作主要集中在src-tauri/src/lyrics.rs文件中，具体分布如下：

// src-tauri/src/lyrics.rs 中的文件删除操作
93:    let _ = remove_file(lrc_path);
96:        let _ = remove_file(txt_path);
107:        let _ = remove_file(lrc_path);
109:        let _ = remove_file(txt_path);
119:    let _ = remove_file(&lrc_path);
120:    let _ = remove_file(txt_path);

这些删除操作涉及两种类型的文件：

• .lrc文件：同步歌词文件
• .txt文件：纯文本歌词文件

1.2 关键函数分析

save_plain_lyrics函数

fn save_plain_lyrics(track_path: &str, lyrics: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;

    let _ = remove_file(lrc_path);

    if lyrics.is_empty() {
        let _ = remove_file(txt_path);
    } else {
        write(txt_path, lyrics)?;
    }
    Ok(())
}

风险点：

• 无条件删除lrc_path，未检查文件是否存在
• 使用let _ =忽略删除操作的结果，无法得知删除是否成功
• 未验证路径是否为歌词文件，存在误删风险

save_synced_lyrics函数

fn save_synced_lyrics(track_path: &str, lyrics: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;
    if lyrics.is_empty() {
        let _ = remove_file(lrc_path);
    } else {
        let _ = remove_file(txt_path);
        write(lrc_path, lyrics)?;
    }
    Ok(())
}

风险点：

• 同样使用let _ =忽略删除操作结果
• 当歌词为空时删除LRC文件，但未通知用户
• 未处理可能的文件权限错误

save_instrumental函数

fn save_instrumental(track_path: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;

    let _ = remove_file(&lrc_path);
    let _ = remove_file(txt_path);

    write(lrc_path, "[au: instrumental]")?;

    Ok(())
}

风险点：

• 连续删除两个文件，但未检查任一操作的结果
• 先删除LRC文件，然后又创建同名文件，逻辑矛盾
• 未验证文件路径是否正确，可能误删重要文件

1.3 路径构建函数分析

fn build_txt_path(track_path: &str) -> Result<PathBuf> {
    let path = Path::new(track_path);
    let parent_path = path.parent().unwrap();
    let file_name_without_extension = path.file_stem().unwrap().to_str().unwrap();
    let txt_path =
        Path::new(parent_path).join(format!("{}.{}", file_name_without_extension, "txt"));

    Ok(txt_path)
}

风险点：

• 使用unwrap()处理可能为None的结果，可能导致程序崩溃
• 未验证生成的路径是否在预期目录内，存在路径遍历风险
• 未检查文件扩展名是否合法

二、文件删除逻辑主要问题诊断

2.1 错误处理机制缺失

LRCGet的文件删除操作存在严重的错误处理缺失问题，主要表现为：

1. 忽略删除结果：所有remove_file调用的结果都被let _ =忽略，无法得知删除操作是否成功。

2. 未处理可能的错误情况：

   • 文件不存在
   • 权限不足
   • 文件正在被使用
   • 路径无效

3. 错误传播中断：使用let _ =而非?操作符，导致错误无法向上传播，调用者无法得知操作失败。

2.2 路径安全问题

1. 路径构建风险：

   • 使用unwrap()处理路径组件，当路径格式异常时会导致程序崩溃
   • 未验证生成的路径是否在预期的歌词文件目录内

2. 缺少路径规范化：未对输入路径进行规范化处理，可能导致路径遍历攻击。

2.3 用户体验问题

1. 无提示删除：所有删除操作都在后台执行，用户无法得知文件已被删除。

2. 无确认机制：对于批量删除或重要文件删除操作，未提供用户确认步骤。

3. 无回滚机制：删除操作一旦执行，无法撤销，用户数据存在丢失风险。

2.4 代码质量问题

1. 代码重复：文件删除逻辑在多个函数中重复实现，违反DRY原则。

2. 缺乏注释：删除操作的目的和副作用未在代码中明确说明。

3. 错误处理不一致：有些函数返回Result，却在关键操作上忽略错误。

三、安全删除操作的最佳实践

3.1 安全删除的核心原则

为了解决LRCGet中的文件删除问题，我们需要遵循以下安全删除原则：

1. 最小权限原则：仅授予程序必要的文件系统访问权限。

2. 确认机制：重要删除操作前必须获得用户确认。

3. 错误处理：不忽略任何删除操作的结果，妥善处理可能的错误。

4. 路径验证：严格验证文件路径，确保只删除预期类型的文件。

5. 操作日志：记录所有删除操作，便于问题排查和数据恢复。

3.2 安全删除流程图

四、文件删除逻辑重构方案

4.1 创建安全删除工具函数

首先，我们需要创建一个集中的、安全的文件删除工具函数，替代直接使用remove_file：

/// 安全删除歌词文件
/// 参数:
/// - file_path: 要删除的文件路径
/// - file_type: 文件类型描述，用于日志和用户提示
/// 返回:
/// - Result<(), Error> 删除结果
fn safe_delete_lyrics_file(file_path: &Path, file_type: &str) -> Result<(), anyhow::Error> {
    // 验证路径是否为歌词文件
    if !is_lyrics_file(file_path)? {
        return Err(anyhow::anyhow!("尝试删除非歌词文件: {:?}", file_path));
    }
    
    // 检查文件是否存在
    if !file_path.exists() {
        log::debug!("{}文件不存在，无需删除: {:?}", file_type, file_path);
        return Ok(());
    }
    
    // 执行删除操作
    log::info!("删除{}文件: {:?}", file_type, file_path);
    match std::fs::remove_file(file_path) {
        Ok(_) => {
            log::info!("{}文件删除成功: {:?}", file_type, file_path);
            Ok(())
        },
        Err(e) => {
            log::error!("{}文件删除失败: {:?}, 错误: {}", file_type, file_path, e);
            Err(anyhow::anyhow!("{}文件删除失败: {}", file_type, e))
        }
    }
}

/// 验证路径是否为歌词文件
fn is_lyrics_file(file_path: &Path) -> Result<bool, anyhow::Error> {
    // 获取文件扩展名
    let ext = match file_path.extension() {
        Some(ext) => ext.to_str().unwrap_or(""),
        None => return Ok(false),
    };
    
    // 检查是否为支持的歌词文件类型
    Ok(ext.eq_ignore_ascii_case("lrc") || ext.eq_ignore_ascii_case("txt"))
}

4.2 重构save_plain_lyrics函数

fn save_plain_lyrics(track_path: &str, lyrics: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;
    
    // 删除LRC文件
    safe_delete_lyrics_file(&lrc_path, "同步歌词(.lrc)")?;
    
    if lyrics.is_empty() {
        // 删除TXT文件
        safe_delete_lyrics_file(&txt_path, "纯文本歌词(.txt)")?;
    } else {
        // 写入TXT文件
        write(txt_path, lyrics)?;
        log::info!("纯文本歌词(.txt)保存成功: {:?}", txt_path);
    }
    
    Ok(())
}

4.3 重构save_synced_lyrics函数

fn save_synced_lyrics(track_path: &str, lyrics: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;
    
    if lyrics.is_empty() {
        // 删除LRC文件
        safe_delete_lyrics_file(&lrc_path, "同步歌词(.lrc)")?;
    } else {
        // 删除TXT文件
        safe_delete_lyrics_file(&txt_path, "纯文本歌词(.txt)")?;
        // 写入LRC文件
        write(lrc_path, lyrics)?;
        log::info!("同步歌词(.lrc)保存成功: {:?}", lrc_path);
    }
    
    Ok(())
}

4.4 重构save_instrumental函数

fn save_instrumental(track_path: &str) -> Result<()> {
    let txt_path = build_txt_path(track_path)?;
    let lrc_path = build_lrc_path(track_path)?;
    
    // 删除现有歌词文件
    safe_delete_lyrics_file(&lrc_path, "同步歌词(.lrc)")?;
    safe_delete_lyrics_file(&txt_path, "纯文本歌词(.txt)")?;
    
    // 创建器乐标记文件
    write(&lrc_path, "[au: instrumental]")?;
    log::info!("器乐标记文件创建成功: {:?}", lrc_path);
    
    Ok(())
}

4.5 改进路径构建函数

fn build_txt_path(track_path: &str) -> Result<PathBuf> {
    let path = Path::new(track_path);
    let parent_path = path.parent()
        .ok_or_else(|| anyhow::anyhow!("无法获取父目录: {}", track_path))?;
    
    let file_name_os = path.file_stem()
        .ok_or_else(|| anyhow::anyhow!("无法获取文件名: {}", track_path))?;
    
    let file_name = file_name_os.to_str()
        .ok_or_else(|| anyhow::anyhow!("文件名不是有效的UTF-8: {:?}", file_name_os))?;
    
    // 验证路径安全性
    let safe_parent = sanitize_path(parent_path)?;
    let txt_path = safe_parent.join(format!("{}.txt", file_name));
    
    // 确保生成的路径在安全目录内
    if !txt_path.starts_with(&safe_parent) {
        return Err(anyhow::anyhow!("路径可能存在遍历攻击: {:?}", txt_path));
    }
    
    Ok(txt_path)
}

// 类似重构build_lrc_path函数...

/// 清理路径，防止路径遍历攻击
fn sanitize_path(path: &Path) -> Result<PathBuf, anyhow::Error> {
    let normalized = path.canonicalize()?;
    
    // 获取应用的歌词目录，假设我们有一个配置项存储这个路径
    let lyrics_dir = get_lyrics_directory()?;
    let lyrics_dir = lyrics_dir.canonicalize()?;
    
    if normalized.starts_with(lyrics_dir) {
        Ok(normalized)
    } else {
        Err(anyhow::anyhow!("路径不在允许的歌词目录内: {:?}", normalized))
    }
}

4.6 添加用户确认机制

对于批量删除或重要文件删除操作，添加用户确认机制：

/// 带用户确认的文件删除
async fn delete_with_confirmation(file_path: &Path, file_type: &str) -> Result<(), anyhow::Error> {
    // 检查是否需要确认
    if !should_confirm_deletion(file_type) {
        return safe_delete_lyrics_file(file_path, file_type);
    }
    
    // 获取文件名用于确认消息
    let file_name = file_path.file_name()
        .and_then(|n| n.to_str())
        .unwrap_or("该文件");
    
    // 调用前端显示确认对话框
    let confirmed = tauri::api::dialog::confirm(
        None,
        format!("确认删除{}", file_type),
        format!("您确定要删除{}吗?\n{}", file_type, file_name)
    ).await;
    
    if confirmed {
        safe_delete_lyrics_file(file_path, file_type)
    } else {
        log::info!("用户取消删除{}: {:?}", file_type, file_path);
        Ok(())
    }
}

/// 判断是否需要删除确认
fn should_confirm_deletion(file_type: &str) -> bool {
    // 可以根据文件类型、大小或其他因素决定是否需要确认
    // 这里简单地对所有批量删除操作要求确认
    file_type.contains("批量") || file_type.contains("全部")
}

五、实施与迁移策略

5.1 分阶段实施计划

为了确保重构的平稳过渡，建议采用以下分阶段实施计划：

阶段	任务	目标
1	添加详细日志	不修改功能，仅添加日志记录所有删除操作
2	创建安全删除工具函数	实现安全删除逻辑，但保留旧代码作为备份
3	替换关键函数中的删除操作	逐步用新的安全删除函数替换旧的删除逻辑
4	添加路径验证和用户确认	增强安全性和用户体验
5	移除旧代码	完成迁移，删除不再使用的旧删除逻辑

5.2 兼容性考虑

1. 数据兼容性：重构不应影响现有歌词文件的格式和内容。

2. 配置迁移：如需添加新的配置项（如歌词目录），需提供自动迁移工具。

3. 回滚机制：保留旧代码一段时间，以便在新实现出现问题时能够快速回滚。

六、总结与展望

LRCGet项目的文件删除逻辑重构是一个典型的安全加固过程，它不仅解决了当前存在的问题，还建立了一套可持续的安全文件操作规范。通过实施本文提出的重构方案，我们可以：

1. 显著提高文件操作的安全性，防止意外删除和恶意攻击
2. 改善错误处理机制，提高程序的健壮性
3. 增强用户体验，让用户对文件操作有更多控制权
4. 建立可维护的代码结构，为未来功能扩展奠定基础

未来，我们还可以进一步增强文件操作的安全性：

1. 实现回收站功能：删除的文件先移至回收站，提供恢复机会
2. 添加操作审计：记录所有文件操作，支持安全审计
3. 文件版本控制：为歌词文件提供版本历史，支持回溯到之前版本
4. 云备份集成：自动备份重要歌词文件到云端存储

通过持续改进和关注安全细节，LRCGet可以成为一个更加可靠、安全的歌词管理工具，为用户提供更好的服务体验。

【免费下载链接】lrcget Utility for mass-downloading LRC synced lyrics for your offline music library. 项目地址: https://gitcode.com/gh_mirrors/lr/lrcget