Windows 向 Vmware Ubuntu 传大文件校验不一致问题完整排查记录

文章目录

- 一、问题背景
- [二、第一反应：是不是 Linux / Windows 算法不一样？](#二、第一反应：是不是 Linux / Windows 算法不一样？)
- - [2.1 结论先行](#2.1 结论先行)
- 三、发现异常：文件大小已经不一致
- - [3.1 Windows 上的文件大小](#3.1 Windows 上的文件大小)
  - [3.2 Ubuntu 中的文件大小](#3.2 Ubuntu 中的文件大小)
  - [3.3 结论](#3.3 结论)
- 四、根因分析：为什么"拖拽/共享目录"会出问题？
- - [4.1 常见但危险的做法](#4.1 常见但危险的做法)
  - [4.2 为什么小文件"看起来没问题"？](#4.2 为什么小文件“看起来没问题”？)
- [五、正确技术路线：使用 SSH / SCP 做"字节级传输"](#五、正确技术路线：使用 SSH / SCP 做“字节级传输”)
- - [5.1 核心原则](#5.1 核心原则)
- [六、实操步骤（一）：确认虚拟机网络 IP](#六、实操步骤（一）：确认虚拟机网络 IP)
- [七、实操步骤（二）：确保 Ubuntu 开启 SSH 服务](#七、实操步骤（二）：确保 Ubuntu 开启 SSH 服务)
- - [7.1 查看状态](#7.1 查看状态)
- [八、实操步骤（三）：使用 SCP 从 Windows 传输](#八、实操步骤（三）：使用 SCP 从 Windows 传输)
- [九、关键验证：大小 + 哈希双重确认](#九、关键验证：大小 + 哈希双重确认)
- - [9.1 Ubuntu 中验证文件大小](#9.1 Ubuntu 中验证文件大小)
  - [9.2 Ubuntu 中计算 SHA256](#9.2 Ubuntu 中计算 SHA256)

本文基于 Windows 11 + VMware Workstation + Ubuntu 24.04 LTS 环境，完整记录了一次 大文件（Android 15 源码分卷）从 Windows 传入 Linux 后 SHA256 校验不一致 的排查过程。

一、问题背景

在同步 Android 15 源码 时，由于网络不稳定，选择了 Windows 本机下载源码分卷文件，再传入 Ubuntu 虚拟机进行解压。

文件示例：

复制代码

android15-r1.tar.bz2.aa

在 Windows 上校验：

powershell 复制代码

Get-FileHash android15-r1.tar.bz2.aa -Algorithm SHA256

得到：

复制代码

2C2AD15A90005168EBFD402FAA4980524C698A9F02F25F90D872F12C4DA661A4

但传入 Ubuntu 后：

bash 复制代码

sha256sum android15-r1.tar.bz2.aa

却得到 完全不同的哈希值。

这意味着：

文件在"传输或存储过程中发生了变化"，绝不能直接解压或使用。

二、第一反应：是不是 Linux / Windows 算法不一样？

这是一个非常常见但错误的怀疑。

2.1 结论先行

SHA256 算法在所有平台上完全一致，只要文件内容一字节不差，结果必然相同。

因此：

校验不一致
≠ 算法问题
= 文件内容发生了变化

接下来要做的，是定位 "在哪一步变了"。

三、发现异常：文件大小已经不一致

3.1 Windows 上的文件大小

powershell 复制代码

dir android15-r1.tar.bz2.aa

结果：

复制代码

Length : 4194304000

即：

4,194,304,000 Bytes（约 3.91 GiB）

3.2 Ubuntu 中的文件大小

bash 复制代码

ls -lh android15-r1.tar.bz2.aa

显示：

复制代码

3.3G

进一步精确查看：

bash 复制代码

stat -c %s android15-r1.tar.bz2.aa

结果并不等于 4194304000。

3.3 结论

文件在传入虚拟机时已经被"截断/重写/压缩"，这不是校验工具问题，而是传输方式的问题。

四、根因分析：为什么"拖拽/共享目录"会出问题？

4.1 常见但危险的做法

很多人会直接：

Windows → 拖文件到虚拟机桌面
或使用 VMware 共享目录（/mnt/hgfs）

这些方式：

❌ 不保证大文件的字节完整性
❌ 可能经过缓存、压缩、分块重组
❌ 中断时无校验、无报错

4.2 为什么小文件"看起来没问题"？

因为：

小文件一次性完成
不触发缓存/分段问题

而 4GB 级别文件：

极容易在中途失败
失败后却"看起来复制成功"

这是最危险的地方。

五、正确技术路线：使用 SSH / SCP 做"字节级传输"

5.1 核心原则

凡是源码 / 镜像 / 压缩包，必须使用可校验的传输协议。

推荐顺序：

scp
rsync
sftp

本文采用 scp（最直观）。

六、实操步骤（一）：确认虚拟机网络 IP

在 Ubuntu 中执行：

bash 复制代码

ip a

得到类似：

复制代码

inet 192.168.11.134/24

说明：

虚拟机与 Windows 在同一局域网（NAT / 桥接）
可以直接通过 IP 访问

七、实操步骤（二）：确保 Ubuntu 开启 SSH 服务

7.1 查看状态

bash 复制代码

sudo systemctl status ssh

若未运行：

bash 复制代码

sudo apt install -y openssh-server
sudo systemctl enable --now ssh

确认监听成功：

复制代码

Server listening on 0.0.0.0 port 22

八、实操步骤（三）：使用 SCP 从 Windows 传输

在 Windows PowerShell 中：

powershell 复制代码

scp android15-r1.tar.bz2.aa cyh@192.168.11.134:/home/cyh/桌面/android15/

说明：

scp = 基于 SSH 的文件复制
传输过程是 原始字节流
中断会直接失败，不会"假成功"

九、关键验证：大小 + 哈希双重确认

9.1 Ubuntu 中验证文件大小

bash 复制代码

stat -c %s android15-r1.tar.bz2.aa

输出：

复制代码

4194304000

✔ 与 Windows 完全一致

9.2 Ubuntu 中计算 SHA256

bash 复制代码

sha256sum android15-r1.tar.bz2.aa

得到：

复制代码

2c2ad15a90005168ebfd402faa4980524c698a9f02f25f90d872f12c4da661a4

与 Windows：

复制代码

2C2AD15A90005168EBFD402FAA4980524C698A9F02F25F90D872F12C4DA661A4

完全一致（大小写无关）。