AList项目中百度网盘挂载的修改时间显示问题分析

在AList项目v3.14及之后的版本中，用户反馈了一个关于百度网盘挂载功能的重要问题：系统错误地将文件/文件夹的创建时间(created)显示为最后修改时间，而实际上应该显示的是修改时间(modified)。这个问题影响了用户对文件更新状态的判断，特别是在需要按最后修改时间排序查看文件夹内容时。

问题现象

当用户通过AList挂载百度网盘后，在网页界面查看文件列表时，所有文件和文件夹的"修改时间"列显示的都是它们的创建时间。例如，一个在2024年更新过的文件夹，其显示的时间仍然是创建日期而非最后修改日期。这使得用户无法准确判断文件夹内容是否更新，也无法按实际修改时间进行排序。

技术背景

在文件系统中，每个文件通常都维护着三个基本时间属性：

1. 创建时间(created)：文件最初被创建的时间
2. 修改时间(modified)：文件内容最后一次被修改的时间
3. 访问时间(accessed)：文件最后一次被访问的时间

对于云存储服务如百度网盘，这些时间属性同样存在。正确的实现应该区分这些时间戳，特别是在文件管理场景中，修改时间是最常被关注和使用的属性。

问题原因

根据分析，这个问题源于AList在v3.14版本后对百度网盘API的响应处理逻辑发生了变化。在获取文件元数据时，系统错误地将"created"字段赋值给了修改时间属性，而没有正确使用"modified"字段。

影响范围

该问题影响了所有使用AList挂载百度网盘并依赖修改时间进行文件管理的用户。特别是在以下场景中影响显著：

• 需要查看最近更新文件的用户
• 依赖修改时间排序来管理工作流的用户
• 需要同步文件并基于修改时间判断是否需要更新的场景

解决方案

要解决这个问题，开发者需要修改百度网盘驱动中对文件元数据的处理逻辑，确保：

1. 修改时间字段从API响应的"modified"字段获取
2. 创建时间字段从"created"字段获取
3. 保持这两个属性的独立性

最佳实践建议

对于文件管理系统开发者，在处理云存储服务的文件元数据时，建议：

1. 仔细阅读各云服务商的API文档，明确各时间字段的含义
2. 实现统一的元数据转换层，确保不同服务商的时间字段被正确映射
3. 在UI层明确区分创建时间和修改时间的显示
4. 考虑添加时间戳的本地缓存机制，提高频繁访问时的性能

这个问题提醒我们，在开发跨云存储的文件管理系统时，正确处理和显示文件元数据是保证用户体验的关键因素之一。