为什么可以在Ubuntu中移动正在运行的程序？

我刚刚意识到我能够将正在运行的活动程序移至其他目录。以我的经验，这在MacO或Windows中是不可能的。它在Ubuntu中如何工作？

编辑：我认为这在Mac上是不可能的，但显然可以通过评论进行验证。也许只有在Windows上才有可能。感谢所有的答案。

让我分解一下。

当您运行可执行文件，系统调用的顺序执行，最显着的fork()和execve()：

• fork()创建调用进程的子进程，该子进程（主要是父进程的确切副本）都仍在运行相同的可执行文件（使用写时复制内存页，因此非常高效）。它返回两次：在父级中，它返回子级PID。在子进程中，它返回0。通常，子进程立即调用execve：

• execve()将可执行文件的完整路径作为参数，并将调用过程替换为可执行文件。此时，新创建的进程将获得其自己的虚拟地址空间（即虚拟内存），并在其入口点开始执行（处于平台ABI的新进程规则所指定的状态）。

此时，内核的ELF加载器已将可执行文件的文本和数据段映射到内存中，就好像它使用了mmap()系统调用一样（分别具有共享的只读和私有读写映射）。BSS也像使用MAP_ANONYMOUS一样进行映射。（顺便说一句，我忽略了动态链接这里简单：动态链接open()S和mmap()一切都跳跃到主可执行文件的入口点之前的动态库）。

在new-exec（）启动开始运行自己的代码之前，实际上只有几页从磁盘加载到内存中。如果/当过程触及其虚拟地址空间的那些部分时，将根据需要按需分页其他页面。（在开始执行用户空间代码之前预加载任何代码或数据页面只是性能优化。）

可执行文件由较低级别的索引节点标识。在开始执行文件之后，内核会通过inode引用而不是文件名来保持文件内容的完整性，就像打开文件描述符或文件支持的内存映射一样。因此，您可以轻松地将可执行文件移动到文件系统的其他位置，甚至移动到其他文件系统上。附带说明一下，要查看流程的各种统计信息，您可以查看/proc/PID（PID是给定流程的流程ID）目录。您甚至可以将可执行文件打开为/proc/PID/exe，即使该文件已从磁盘取消链接。

现在让我们深入研究一下：

在同一文件系统中移动文件时，执行的系统调用为rename()，只是将文件重命名为另一个名称，文件的inode保持不变。

在两个不同的文件系统之间，发生两件事：

• 首先通过read()和将文件内容复制到新位置write()

• 之后，使用取消该文件与源目录的链接unlink()，显然该文件将在新文件系统上获得一个新的inode。

rm实际上只是unlink()从目录树中访问给定的文件，因此具有目录的写许可权将使您有足够的权利从该目录中删除任何文件。

现在，为了好玩，想象一下当您在两个文件系统之间移动文件而又没有unlink()源文件的许可时会发生什么？

那么，该文件将首先复制到目标（read()，write()），然后unlink()将由于权限不足失败。因此，该文件将保留在两个文件系统中！

好吧，这很简单。让我们以一个名为/ usr / local / bin / whoopdeedoo的可执行文件为例。那只是对所谓的inode（Unix文件系统上文件的基本结构）的引用。标记为“使用中”的索引节点。

现在，当您删除或移动文件/ usr / local / whoopdeedoo时，唯一被移动（或擦除）的是对索引节点的引用。索引节点本身保持不变。基本上就是这样。

我应该进行验证，但是我相信您也可以在Mac OS X文件系统上执行此操作。

Windows采用不同的方法。为什么？谁知道...？我对NTFS的内部并不熟悉。从理论上讲，所有使用对文件名的内部结构的引用的文件系统都应该能够做到这一点。

我承认，我过于简化了，但是请阅读Wikipedia上的“含义”部分，该部分比我做的要好得多。

其他所有答案似乎都缺少的一件事是：一旦打开文件并且程序保存了打开的文件描述符，则在关闭该文件描述符之前，不会从系统中删除该文件。

尝试删除引用的索引节点将被延迟，直到文件关闭：在相同或不同文件系统中重命名不会影响打开的文件，而与重命名行为无关，也不会显式删除或覆盖新文件。弄乱文件的唯一方法是显式打开文件的inode并弄乱内容，而不是通过对目录的操作（如重命名/删除文件）来进行处理。

此外，当内核执行文件时，它会保留对可执行文件的引用，这将再次防止在执行过程中对其进行任何修改。

因此，最后即使您看起来能够删除/移动组成正在运行的程序的文件，实际上这些文件的内容仍保留在内存中，直到程序结束。

在Linux文件系统中，当您移动文件时，只要它不跨越文件系统边界（读取：位于同一磁盘/分区上），您所要做的就是将..（父目录）的inode 移至新位置的inode。。实际数据根本没有在磁盘上移动，只是在指针上没有移动，因此文件系统知道在哪里可以找到它。

这就是为什么移动操作如此快速的原因，并且可能是为什么移动一个正在运行的程序没有问题的原因，因为您实际上并不在移动程序本身。

这是可能的，因为移动程序不会影响通过启动程序启动的正在运行的进程。

启动程序后，将保护其磁盘位不被覆盖，但是无需保护要重命名的文件，将其移动到同一文件系统上的其他位置（等效于重命名文件或将其移动）到另一个文件系统，相当于将文件复制到其他位置然后将其删除。

删除正在使用的文件，要么是因为某个进程打开了文件描述符，要么是因为某个进程正在执行该文件，但不会删除文件数据，该数据仍由文件inode引用，只会删除目录项，即可以从其到达inode的路径。

请注意，启动程序不会一次将所有内容加载到（物理）内存中。相反，仅加载启动过程所需的严格最低要求。然后，在整个过程中按需加载所需的页面。这称为需求分页。如果RAM不足，则OS可以自由释放保存这些页面的RAM，因此进程很有可能从可执行索引节点中多次加载同一页面。

Windows无法实现的原因最初可能是由于基础文件系统（FAT）不支持目录项与inode的分离概念。NTFS不再存在此限制，但操作系统设计已保留了很长时间，这导致安装新版本的二进制文件时不得不重新启动的讨厌限制，而最新版本的Windows不再是这种情况。

基本上，在Unix及其类似版本中，文件名（包括指向该文件的目录路径）用于在打开文件时关联/查找文件（执行文件是一种以某种方式打开文件的方式）。在那一刻之后，将确定文件的身份（通过其“ inode”），并且不再受到质疑。您可以删除文件，重命名文件，更改其权限。只要任何进程或文件路径在该文件/ inode上都有一个句柄，它就会一直存在，就像进程之间的管道一样（实际上，在历史悠久的UNIX中，管道是一个无名的inode，其大小恰好适合inode中的“直接块”磁盘存储参考（大约10个块）。

如果您在PDF文件上打开了PDF查看器，则可以删除该文件并打开一个具有相同名称的新文件，并且只要打开旧的查看器，仍然可以很好地访问旧文件（除非它可以主动监视）文件系统，以便在文件以其原始名称消失时发出通知）。

需要临时文件的程序可以以某种名称打开这样的文件，然后在它仍处于打开状态时立即将其删除（或更确切地说是其目录条目）。之后，无法再通过名称访问该文件，但是任何具有打开的文件描述符的进程仍可以访问该文件，并且如果此后程序意外退出，则该文件将被删除并自动回收存储。

因此，文件的路径不是文件本身的属性（实际上，硬链接可以提供几个不同的此类路径），仅在打开文件时才需要，而对于已经打开该文件的进程不需继续访问。