libarchive项目中的FILETIME时间精度问题解析

在Windows平台上使用libarchive库进行文件解压操作时，开发人员可能会遇到一个微妙但重要的问题——文件时间戳的精度丢失。具体表现为文件最后修改时间的纳秒级精度部分在解压后被截断，导致时间戳信息不完整。

问题现象

当开发者在Windows系统上创建一系列具有细微时间差（100纳秒间隔）的文件，并将它们打包成7z格式后，使用libarchive进行解压时，会发现解压后的文件时间戳精度出现了问题。原始文件中精确到100纳秒的时间戳在解压后丢失了最后一位数字，导致所有文件的时间戳都被统一截断为相同的值。

技术背景

Windows系统使用FILETIME结构来存储文件时间戳，这种时间表示方式具有以下特点：

1. 时间精度为100纳秒（即0.1微秒）
2. 时间起点为1601年1月1日UTC
3. 采用64位无符号整数表示
4. 每单位代表100纳秒间隔

这种高精度时间戳对于需要精确文件版本控制的场景尤为重要，特别是在自动化构建系统或文件同步工具中。

问题根源

通过分析libarchive的源代码，发现问题出在archive_write_disk_windows.c文件中的时间转换处理逻辑。具体来说，在将纳秒级时间戳转换为Windows FILETIME格式时，代码中存在一个整数除法运算错误：

原始代码将纳秒值(nsec)先除以1000，然后再乘以10。这种处理方式会导致纳秒部分的最后一位数字被截断。例如，对于99999900纳秒（即9999990×10纳秒），经过除以1000得到99999，再乘以10得到999990，丢失了最后一位0。

解决方案

修复方案非常简单：将原来的(((nsec)/1000)*10)计算方式改为((nsec)/100)。这样修改后：

1. 保持了正确的数学等价性
2. 避免了中间步骤的精度损失
3. 确保最终结果保留了完整的100纳秒精度

影响范围

这个问题会影响所有使用libarchive在Windows平台上进行文件解压操作的场景，特别是：

1. 需要精确保留文件元数据的备份恢复工具
2. 文件同步和版本控制系统
3. 自动化构建系统
4. 任何依赖精确文件时间戳的应用程序

最佳实践建议

对于需要在Windows平台上处理文件时间戳的开发者，建议：

1. 始终使用最新版本的libarchive库
2. 在关键应用中验证文件时间戳的完整性
3. 考虑在应用层添加时间戳验证逻辑
4. 对于需要最高时间精度的场景，可以考虑使用Windows原生API进行补充验证

总结

文件时间戳的精度问题虽然看似微小，但在某些特定场景下可能导致严重后果。libarchive作为广泛使用的归档库，其时间处理逻辑的正确性至关重要。通过理解这个问题的技术细节，开发者可以更好地在自己的应用中处理类似的时间精度问题，确保文件元数据的完整性。