☰

将 /bin 内容移至 /usr/bin，可以撤消吗？

tag-icon • tag-icon linux ubuntu mv
将 /bin 内容移至 /usr/bin，可以撤消吗？

运行 Ubuntu 17.04，我正在从非存储库发行版安装软件，我应该将软件 bin 文件夹内容移动到 /usr/bin （这已经是不确定的建议）

这是那些日子之一，所以我做了什么：

mv /bin/* /usr/bin

所以我搞砸了，我不小心将 bin 中的所有文件移动到 /usr/bin ，而 /bin 是空的。由于我认为 /bin 对系统至关重要，为了快速补救，我将 /usr/bin 内容复制到 /bin。

现在我的 /bin 和 /usr/bin 内容相同，并且都包含最初位于 /bin 和 /usr/bin 中的文件。

  1. 我的 Ubuntu 现在处于损坏状态吗？ （尚未尝试重新启动计算机，现在一切似乎仍然有效）
  2. 有没有办法知道哪些文件最近被移动/复制到 /usr/bin ，这样我就可以手动处理这种情况？ 2.1 /bin 和 /usr/bin 中是否经常存在重叠文件
  3. 还有其他方法可以撤销我所做的事情吗？

我没有安装 Timeshift，因此恢复备份不是一个选项，但目前计算机上没有什么关键的东西，所以我只能承认搞砸了重新安装整个 Linux 分区。

答案1

/usr/bin在 Linux 上（以及大多数其他系统上，尽管 POSIX 不会为您提供这种保证，除非移动是跨文件系统），这会更新它们的 ctime，因此假设在过去 24 小时内没有触及其他系统，您应该能够通过以下方式将它们移回来：

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

echo如果看起来正确，请将其删除。请注意，您将无法恢复/bin和中存在的同名文件/usr/bin（中的原始文件/usr/bin将会丢失）

/bin一个潜在的警告：如果某些文件在和中都被硬链接/usr/bin，则所有硬链接/usr/bin都将被移动到/bin。

现在，您可能会认为，由于/bin和/usr/bin位于默认值中$PATH，并且至少/bin在安装之前可用，因此可执行文件是否位于而不是 中并不重要。/boot/usr/bin/usr/bin

但这会忽略许多命令对可执行文件的路径进行硬编码，并期望它们在某些特定情况下。一个常见的例子是她的刘海。所有具有以下内容的脚本：

#! /usr/bin/env bash

这样做后将无法工作mv /usr/bin/env /bin/env。在这方面，将命令放在两个位置更安全，因为它不会破坏这些脚本。

答案2

我的 Ubuntu 现在处于损坏状态吗？

是的，你的 Ubuntu 坏了

你搞砸了一些重要的事情包管理。

因此，在实践中，请备份您的重要数据（至少/etc和/home），也许还有已安装软件包的列表，例如 的输出dpkg -l，然后重新安装 Ubuntu。

（非新手可以尝试管理 - 就像其他答案一样 - 但他就不会犯如此巨大和基本的错误）

我只能承认把整个 Linux 分区搞砸了。

这可能会花费更少的时间。在其他答案的帮助下保持当前的系统会使其处于非常混乱的状态（这会给您带来未来的麻烦）。

由于您正在重新格式化磁盘，请考虑放置/home一个单独的分区（这样将来此类错误就不会丢失您的数据）。在执行此操作之前，请在纸上打印df -h和的输出（它们提供有关磁盘空间的信息 - 已使用的和可用的 - ...）。明智的做法是拥有足够大的系统分区（根文件系统）；如果你能负担得起的话，100 GB 就足够了。df -hifdisk -l

我应该将软件 bin 文件夹内容移动到 /usr/bin

（术语：Unix 有目录，而不是“文件夹”）。

那 （移动）是/usr/bin/非常错误的。要么提高你的$路径（最好）或最多添加符号链接并/usr/bin/最好将可执行文件移动（或添加符号链接）到/usr/local/bin/.

明智的方法是永远不要在包管理工具（例如，，，等等） 之外进行/usr/bin/更改。阅读/bin/sbin/usr/sbin/dpkgapt-getaptitudeFHS。

答案3

  1. 您的安装应该基本没问题；/usr和中不应该有同名的不同文件/usr/bin（这会回答您的2.1），因此将所有文件放在 和 中/bin不会/usr/bin破坏任何东西（直到您升级软件包）。如果您用符号链接覆盖了二进制文件，那么您现在可能遇到的唯一问题是符号链接损坏。要解决此问题，请查找损坏的符号链接：

    find -L /bin /usr/bin -type l -ls

    并重新安装与列出的文件相对应的任何软件包（例如，如果/usr/bin/zsh显示为损坏，dpkg -S /bin/zsh /usr/bin/zsh则会告诉您该文件来自哪个软件包；使用 重新安装apt --reinstall install zsh）。

  2. 您可以按 ctime 显示和排序以查看最近更改的文件（其中包括您移动的文件）：

    ls -ltc /bin

  3. 撤消所做操作的最佳方法是使用该cruft包并删除它在包中找到的文件/bin或/usr/bin不来自包的文件：

    sudo apt install cruft
sudo cruft -d "/ /usr"

    除非这些文件是指向文件的符号链接/etc/alternatives（在这种情况下，您应该保留它们）。

答案4

详细阐述可能是有教育意义的为什么您的系统或多或少地“损坏”了。

  1. /bin正如 @basile-starynkevitch 指出的那样，如果包管理系统在应该位于 的位置找到了二进制文件，则可能会变得非常混乱/usr/bin，反之亦然。
  2. 某些（可能很重要）脚本可能会通过硬连接在一个目录或另一个目录中查找特定的二进制文件（在某些情况下，这是一种很好的做法，例如从安全角度来看，不是依赖于）的内容$PATH。
  3. /bin和之间存在区别的原因/usr/bin是前者可能位于引导早期阶段安装的分区上。在这种情况下（即，当引导系统时），不仅/bin/xxx二进制文件可能由完整路径引用，而且该目录/usr/bin此时可能在系统上不可用。 （如果您df /bin和df /usr/bin，您可能会看到列出相同的文件系统或不同的文件系统；现在大多数默认安装可能会将两个目录保留在同一分区中）。

因此，如果你有相同的/bin和中都有二进制文件/usr/bin，那么问题 2 和 3 就不会发生，并且问题 1 造成的损害可能很小。例如，Re 1，如果您尝试删除软件包，则可能无法正确卸载它们；如果升级尝试升级“正确”位置的副本，但忽略“错误”位置的副本，则升级可能会出现乱码。因此，如果上述补救措施看起来过于激烈或复杂，您可能让系统保持这种状态就可以了。

但如果这是一个重要的系统，我真的我不会指望这一点。

一般规则（再次呼应@basile-starynkevitch）是永远不要与/usr/bin,/bin和朋友们胡闹——他们“属于”发行版——并且建议将这样做作为其正常安装的一部分的软件包......不是一个好的软件包。

编辑：与第3点相关，有一个在 systemd/Fedora 和朋友的背景下进行讨论为什么将所有内容移至/binto/usr/bin并将第一个内容符号链接到第二个内容是有意义的。这是不是建议你自己这样做——该页面是写给发行版的人的——但它包括了为什么这种区别存在的一些历史（以及暗示为什么它现在只是尘封的传统）。

相关内容