为什么 Shell 脚本一经过 Windows，执行权限就神秘消失？

今天被这个坑了，写下来总结一下。

嘿，各位在代码世界中探索的朋友们！

你是否经历过这样一个令人百思不得其解的场景：

在你的 Linux 开发机上，你精心撰写了一个 shell 脚本，赋予它 chmod +x 的神力，它执行起来如臂使指，一切尽在掌握。然后，你只是想把这个脚本交给同事，于是顺手把它拖到了 Windows 共享目录，或是用 U 盘中转了一下。

然而，当这个脚本在新家的 Linux 系统上准备大展拳脚时，却被无情地拒之门外：

你 ls -l 一看，原本 rwxr-xr-x 的赫赫神功，竟变成了 rw-r--r-- 的平庸之辈。你不禁仰天长叹："我的执行权限去哪了？难道文件内容在旅途中被 Windows 修改了？"

如果你曾有过这样的疑惑，那么恭喜你，你即将踏上一场揭开操作系统底层秘密的侦探之旅。这篇文章，将带你从现象到本质，彻底终结这个困扰。

第一章：初步侦查 —— 文件内容真的被修改了吗？

在深入调查之前，我们要先排除一个最大的嫌疑。很多人的第一直觉是："我的文件肯定被 Windows动过手脚了！"

这里，我可以给你一个斩钉截铁的答案：没有！

你的文件内容，从 #!/bin/bash 到最后一个字符，一个字节都没有变。你可以用 md5sum 或 diff 等工具来验证，你会发现从 Linux 出发的和历经沧桑归来的文件，其内容 (Content) 完全一致。

那么，如果内容没变，丢失的到底是什么？

这引出了我们理解整个问题的核心概念，也是本次探案的第一个关键线索。

关键线索 #1：文件内容 ≠ 文件属性

为了让你秒懂这个概念，我们来建立一个贯穿全文的比喻：

一个文件，就像一本书。它由两部分组成："书的内容"和附带的"图书卡"。

书的内容 (Content)：就是文件里存储的代码、文字、图片等二进制数据。这是文件的灵魂。图书卡 (Metadata)：这是一张记录关于这本书信息的卡片，比如书名（文件名）、作者（所有者）、出版日期（修改时间），以及一个至关重要的东西——一个代表身份和权限的特殊印章。

在这个比喻里，可执行权限 (+x)就是盖在这张图书卡上的一个红色印章。

有了这个概念，我们再来看看那趟致命的 Windows 之旅到底发生了什么。我将用三张图为你分解这个过程：

第一站：在 Linux 起点，一切安好

在源头的 Linux 系统上，你的脚本文件和它的"图书卡"（元数据）是完美配对的。图书卡上清晰地盖着"可执行"的印章。

第二站：在 Windows 中转，信息丢失

当你将文件复制到 Windows 系统时，Windows 只认识"书的内容"，但完全无法理解 Linux 的"图书卡"格式。于是，它只保留了内容，而将带有关键权限印章的图书卡无情地抛弃了。

第三站：在 Linux 目的地，被赋予新身份

当这个只有"内容"的文件回到一个新的 Linux 环境时，系统发现它没有"图书卡"，于是就按照默认的规则，给了它一张全新的、空白的卡片。这张新卡片上，自然没有"可执行"的印章。

真相大白： 文件并未"武功全废"，只是它的"武功秘籍认证"（元数据）在旅途中遗失了。

第二章：深入追查 —— 文件究竟由什么组成？

"原来是图书卡丢了！"你恍然大悟。但要真正理解为什么会丢失，我们需要更进一步，揭开 Linux 系统下文件构成的真实面貌。抛开比喻，一个文件在磁盘上到底是如何存储的？

在 Linux 文件系统（如 ext4）中，一个我们所认知的文件，其信息被分散在三个关键部分：目录项 (Directory Entry)、索引节点 (Inode) 和 **数据块 (Data Blocks)**。让我们逐一了解这三部分：

1. 目录项 (Directory Entry) —— 文件的"名片"

目录项是最容易理解的部分。它就像是文件在系统中的"名片"，包含文件名和一个指向其"身份证"的链接。

重要的是，目录本身也是一个文件！它的内容就是一个表格，记录着该目录下所有文件的名称和对应的 Inode 编号。当你执行 ls 命令时，系统就是读取这个目录文件的内容。

2. 索引节点 (Inode) —— 文件的"身份证"

Inode 是我们前面比喻中的"图书卡"。每个文件都有一个唯一的 Inode，它存储了文件的所有元数据（除了文件名）。

注意看：文件权限信息 rwxr-xr-x 就存储在 Inode 中。这就是为什么当文件通过不支持 Inode 的系统（如 Windows）传输时，权限会丢失。

3. 数据块 (Data Blocks) —— 文件的"实际内容"

数据块存储的是文件的真正内容。对于我们的脚本来说，就是从 #!/bin/bash 开始的所有代码。

大文件的内容可能会分散在多个数据块中，Inode 会保存指向所有这些块的指针。

4. 三者之间的关系：按图索骥

现在，让我们看看这三部分是如何协同工作的：

当你通过文件名访问 myscript.sh 时，系统的工作流程是：

在当前目录中查找 myscript.sh 这个目录项从目录项中获取其对应的 Inode 编号 (#131075)通过编号找到 Inode，检查权限，并获取文件元数据根据 Inode 中的指针，找到并读取数据块，呈现文件内容

现在，一切都清晰了：文件权限，作为元数据的一部分，牢牢地存放在 Inode 中，它和文件内容（数据块）是物理分离的。

当文件被复制到 Windows 系统时，由于 Windows 不使用 Inode 这套机制，它只能读取并保存文件内容（数据块），而描述文件属性的 Inode 信息则被完全抛弃。这就是跨系统后权限丢失的根本原因。

第三章：终极谜题 —— 为何 SCP 能"穿越时空"传递权限？

看到这里，聪明的你肯定会立即提出那个直击灵魂的追问：

"等一下！如果权限不在文件内容里，那为什么我用 scp 直接在两台 Linux 之间复制，权限就不会丢失呢？scp 是如何把那张看不见的图书卡也一并送过去的？"

这个问题，将我们的调查引向了最高潮。答案是：scp 走的不是简单的货物搬运，而是一个有严格流程的"专业信使协议"。

让我们升级比喻：scp 的过程，是两位专业图书馆管理员之间的一通加密电话。

我们来看看这个过程的每一步：

步骤 1：建立安全连接

首先，两台 Linux 机器需要建立一个安全的通信渠道。

这就像两位图书馆管理员拿起加密电话，确认了对方的身份。

步骤 2：元数据先行

与普通文件复制不同，scp 会先传送文件的"图书卡"信息。

源头管理员A说："在寄送书本内容之前，我先告知你这本书的图书卡信息：它的权限是 755，修改时间是……"

步骤 3：准备容器

目标机器收到元数据后，会先创建一个具有正确权限的空文件。

目标管理员B说："好的，信息收到。我已在本地准备好一个空文件，并**立刻将其权限也设置为 755**。"

步骤 4：传输文件内容

只有在容器准备好后，才开始传输实际的文件内容。

管理员A开始逐字逐句地念书的内容（传送二进制数据）。管理员B则将这些内容写入刚才准备好的那个带有正确权限的空文件中。

步骤 5：完整过程对比

让我们对比一下普通复制和 SCP 的区别：

最终结论：scp 之所以能成功传递权限，是因为它是一个智慧协议。它在传送文件内容之前，会先进行"元数据通信"，让接收方提前准备好一个具有正确属性的"容器"，然后再将内容"注入"。这是一个定义清晰、步骤严谨的专业流程。

第四章：探案结束 —— 我们的行动手册

现在，谜底已经完全揭开。作为日常开发者，我们需要一份简单实用的行动手册。

方案一：亡羊补牢（手动修复）

如果文件已经"失忆"，别担心，只需一招就能让它恢复功力。在目标 Linux 机器上：

方案二：防患未然（专业运输）

如果需要在 Linux 之间频繁传送并保持属性，请选择以下"VIP 通道"：

scp -p： -p 参数明确告诉 scp，请务必带上权限、时间等元数据。rsync -a： -a (归档模式) 是 rsync 的王牌，能完美同步包括权限在内的几乎所有属性。tar 打包：先在源头将文件打包成 .tar 文件，tar 会将元数据一同存档。再传送这个单一的压缩包，到目的地解压即可原样还原。

结语

从一个小小的 Permission denied，我们一路追查，从文件内容与元数据的分离，到 Linux Inode 的底层结构，再到 scp 的智慧协议。希望这次的侦探之旅，不仅解决了你眼前的困惑，更能让你对日常使用的工具有了更深刻的理解。

技术的世界，正是由这些看似微小却设计精巧的细节构成。保持好奇，不断追问，你会发现更多乐趣。