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

18

运行Ubuntu 17.04，我正在从非存储库发行版中安装软件，我应该将bin-folder内容移至/ usr / bin（这已经很不明智了）

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

mv /bin/* /usr/bin

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

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

我的Ubuntu现在处于损坏状态吗？（尚未尝试重新启动计算机，现在一切似乎仍然可以正常工作）
有没有办法知道最近将哪些文件移动/复制到了/ usr / bin，所以我可以手动处理这种情况？2.1 / bin和/ usr / bin中通常有重叠的文件
还有其他方法可以撤消我的工作吗？

我没有安装Timeshift，因此不能选择恢复备份，但是当前计算机上没有任何关键操作，因此我可以承认重新安装整个linux分区是不合法的。

— 那些日子中的一天
source

2

dpkg-query -l | awk'{system（“ dpkg-query -L” $ 2“ | grep -E \” ^ / usr / bin /.*$ \“”）}'这将使您最初基于/ usr / bin的所有文件基于安装的软件包

— Raman Sailopal

7

@SatōKatsura对/bin系统至关重要。它的内容必须在最早的引导阶段出现。您不想创建指向/usr无法在引导时挂载的分区的符号链接（在此）。

— xhienne

1

@xhienne我从没说过重启后还能幸免。这是一个临时修复程序，以获取足够的功能来修复系统。

— 佐藤桂

1

@xhienne取决于您如何设置发行版。例如，Arch /bin默认情况下不维护单独的名称。Ubuntu的默认分区不会创建单独的/usr分区。我很好奇实际上有多少人/usr用现代发行版制作了独立唱片。

— muru

1

@muru请以我的普通评论为准。您可能会假设要在分区数量上进行任何操作，我不愿意这样做，并且警告您不要将/ usr / bin / *链接到/ bin，这充其量是完全无用的，最坏的情况是可能使系统在下次启动时无法使用。遵循FHS的任何系统都不应包含指向/ usr / bin的符号链接。建议OP改为复制文件。

— xhienne

19

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

是的，您的Ubuntu坏了

您弄乱了对软件包管理很重要的东西。

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

^{（非新手可以尝试进行管理-就像其他答案一样，但那样他就不会犯这样大而基本的错误）}

我可以承认要重新安装整个linux分区。

那可能会减少您的时间。在其他答案的帮助下使当前系统保持在非常混乱的状态（这将使您将来头疼）。

由于您正在重新格式化磁盘，因此请考虑放入/home单独的分区（这样以后，此类错误就不会丢失您的数据）。在纸上打印之前，先输出df -hand df -hi和fdisk -l（它们提供有关磁盘空间的信息-已使用和可用-...）。拥有足够大的系统分区（根文件系统）是明智的；如果您能负担得起100 GB，那就绰绰有余了。

我应该将软件bin -folder的内容移动到/ usr / bin

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

这（移动到/usr/bin/）是非常错误的。无论是提高你的$ PATH（最好），或至多可加符号链接中/usr/bin/，最好移动（或添加符号链接）可执行文件/usr/local/bin/。

明智的做法是永远不会改变/usr/bin/，/bin，/sbin，/usr/sbin/ 的软件包管理工具外（例如dpkg，apt-get，aptitude等...）。阅读FHS。

— 巴西勒·斯塔林凯维奇
source

4

将接受此答案：似乎在尝试恢复后一直有效，直到重新启动为止，重新启动后无法启动任何桌面环境会话。与其尝试解决这个问题，不如说是我搞砸了，只会重新安装linux分区。由于所有内容都在版本控制上，而且我只用了一周的时间，所以我真正失去的只是尊严，并有轻微的恐慌发作，但是当生活教给我一堂课时，这似乎很正常。

— oneOfThoseDays

1

至于/bin和/usr/bin现在一样，我不知道为什么包管理将被搞砸了。是否真的在那里的情况下/bin/foo，并/usr/bin/foo都通过包（S）上。如果没有，那么周围只会有一些多余的文件。

— StrongBad

3

@Basile不，不会（不开心）；程序包管理只关心它知道的文件，不会抱怨它不知道的文件。即使对于它确实知道的文件，如果文件已更改，也不会特别烦恼……

— Stephen Kitt

2

@Basile我也不会指望后半部分“（一个非新手可以尝试管理-像其他答案一样-但他不会犯这么大而基本的错误）”是真的；-)。甚至专家有时也会溜走！

— 斯蒂芬·基特

1

FWIW我主系统的/分区是12GB，尽管我将其用于KDE上的开发（读取头文件和许多工具），办公和设计（读取重型工具），但我从未遇到空间问题。如果不分割/var，则增加4GB的空间；如果您想要比我更大的余量，则增加25％；在20GB的空间中，您的价值还不错。

— 光谱“

36

在Linux上（以及在大多数其他系统上，尽管除非跨文件系统进行迁移，否则POSIX不会给您保证），这将更新其ctime，因此，假设/usr/bin在过去的24小时中没有碰到其他任何ctime ，您应该可以通过以下方式将它们移回：

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。在这方面，在两个位置都包含命令比较安全，因为它不会破坏这些脚本。

— StéphaneChazelas
source

3

正如上面提到的（我删除了我的评论，因为它有一个严重的错误，它将试图将所有内容移至i--sorry！目录），例如Ubuntu，find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +因为GNU Coreutilsmv支持，所以可以使用-t。其他操作系统通常不支持它，也不能在BusyBox提供的替代版本中mv使用。

— 伊莱亚·卡根

17

您的安装应该基本可以；不应该有在同一个名称不同的文件/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）。
您可以按ctime显示和排序，以查看最近更改的文件（其中将包括您移动的文件）：
```
ls -ltc /bin
```
撤消所做操作的最佳方法是使用cruft程序包并删除它在程序包中找到的/bin或/usr/bin不是程序包中的文件：
```
sudo apt install cruft
sudo cruft -d "/ /usr"
```
除非文件是其中的文件的符号链接/etc/alternatives（在这种情况下，您应该不理会它们）。

— 斯蒂芬·基特
source

以#! /bin/sh或类似开头的脚本除外。

— 桂桂聪（SatōKatsura）

@SatōKatsura如果它们都sh在/bin和中，它们仍然可以正常工作/usr/bin（现在所有文件都已复制）。

— 斯蒂芬·基特

1

cruft这项工作不需要特殊的工具，因为程序包管理器还会跟踪已安装的文件。参见unix.stackexchange.com/questions/153260/…。

— Ned64 '17

1

comm -12 <(ls /bin) <(ls /usr/bin)在我测试过的Ubuntu系统上显示一些条目。有些带有a的/bin/foo -> /usr/bin/foo手段foo将丢失。

— 斯特凡Chazelas

@Stéphane啊，是的，移动链接会破坏原来的位置……

— Stephen Kitt

6

详细说明您的系统或多或少被“破坏”的原因可能具有教育意义。

正如@ basile-starynkevitch指出的那样，如果程序包管理系统在/bin应将二进制文件放在应有的位置时发现二进制文件，则它可能会造成极大的困惑/usr/bin，反之亦然。
某些（可能很重要）的脚本可能很难在一个目录或另一个目录中找到特定的二进制文件（在某些情况下，这是一种好习惯，例如，从安全角度考虑，不要依赖的内容$PATH）。
/bin和之间存在区别的原因/usr/bin是，前者可能位于引导的较早阶段安装的分区上。在这种情况下（即，在引导系统时），/bin/xxx二进制文件不仅可能由完整路径引用，而且此时目录/usr/bin可能在系统上不可用。（如果df /bin和df /usr/bin，您可能会看到列出的相同文件系统或不同的文件系统；这些天，可能是大多数默认安装，将两个目录保留在同一分区中）。

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

但是，如果这是一个重要的系统，我真的不会依靠它。

一个总的规则（再次回声@ basile-starynkevitch）是永远不要与/usr/bin，/bin和朋友胡闹-他们“属于”发行版-一个软件包，建议这样做是其正常安装的一部分……不是一个好软件包。

编辑：与第3点相关，在systemd / Fedora和朋友的上下文中有一个讨论，为什么将所有内容/bin移到/usr/bin并将第一个符号链接到第二个符号是有意义的。这不是建议您自己进行的操作-该页面是针对进行发行的人员-而是包含这种区别存在的历史（并暗示为什么现在只是尘土飞扬的传统）。

— 诺曼·格雷（Norman Gray）
source