Перемещено содержимое / 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.

Мой Ubuntu в сломанном состоянии сейчас?

Да, твоя Ubuntu сломана

Вы испортили что-то важное для управления пакетами .

Таким образом, на практике, сделайте резервную копию ваших важных данных (по крайней мере, /etcи /home), возможно, также список установленных пакетов, например, вывод dpkg -lи переустановите Ubuntu.

^{(неопытный может попытаться справиться - как в других ответах - но тогда он не сделал бы такой огромной и основной ошибки)}

Я мог бы просто допустить, чтобы переустановить весь раздел Linux.

Это, вероятно, то, что будет занимать меньше вашего времени. Поддержание вашей нынешней системы с помощью других ответов приводит к тому, что она находится в очень грязном состоянии (что приведет к будущим головным болям).

Поскольку вы переформатируете свой диск, рассмотрите возможность /homeразмещения отдельного раздела (чтобы в будущем такие ошибки не потеряли ваши данные). Перед этим напечатайте на бумаге выходные данные df -hи df -hiи fdisk -l(они дают информацию о дисковом пространстве - как используемом, так и доступном - ...). Желательно иметь достаточно большой системный раздел (корневую файловую систему); если вы можете себе это позволить, 100 Гбайт более чем достаточно.

Я должен был переместить содержимое папки bin программы в / usr / bin

(терминология: в Unix есть каталоги, а не «папки»).

Это ( переход к /usr/bin/) очень неправильно. Либо улучшайте свой $ PATH (предпочтительно), либо, самое большее, добавляйте символические ссылки в /usr/bin/и предпочтительно перемещайте (или добавляйте символические ссылки) исполняемые файлы /usr/local/bin/.

Мудрый подход к никогда не изменится /usr/bin/, /bin, /sbin, /usr/sbin/ за пределами инструментов управления пакетами (например dpkg, apt-get, aptitudeи т.д. ...). Прочитайте FHS .

В Linux (и в большинстве других систем, хотя POSIX не дает вам такой гарантии, если бы не было перемещения по файловым системам), это обновило бы их ctime, поэтому при условии, что ни одна из других /usr/binне была затронута за последние 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. В связи с этим наличие команд в обоих местах безопаснее, поскольку они не нарушают эти сценарии.

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. Вы можете показать и отсортировать по времени, чтобы увидеть файлы, которые были недавно изменены (которые будут включать файлы, которые вы переместили):

   ls -ltc /bin
   

3. Лучший подход , чтобы отменить то , что вы сделали это использовать cruftпакет и удалять файлы , которые он находит в /binили /usr/binкоторые не входят в пакет:

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

   если файлы не являются символическими ссылками на файлы в /etc/alternatives(в этом случае вы должны оставить их в покое).

Может быть полезно выяснить, почему ваша система в большей или меньшей степени «сломана».

1. Как указывает @ basile-starynkevitch, система управления пакетами может ужасно запутаться, если обнаружит двоичные файлы, /binкогда они должны быть /usr/bin, и наоборот.
2. Некоторые (возможно, важные) сценарии могут быть жестко привязаны к определенному двоичному файлу в одном или другом каталоге (в некоторых случаях рекомендуется, например, с точки зрения безопасности, не полагаться на содержимое $PATH).
3. Причина, по которой существует различие между /binи /usr/binзаключается в том, что первый потенциально может находиться в разделе, который смонтирован на более ранней стадии загрузки. В этом контексте (т. Е. При загрузке системы) не только /bin/xxxдвоичные файлы, вероятно, будут указываться по полному пути, но каталог /usr/binможет быть недоступен в системе в этот момент. (Если вы df /binи df /usr/bin, возможно, видите одну и ту же файловую систему в списке или разные; вероятно, большинство установок по умолчанию в наши дни оставляют оба каталога в одном разделе).

Таким образом , вы можете doubless видеть , что если у вас есть такие же двоичные файлы в обоих /binи /usr/bin, затем проблемы 2 и 3 не будет происходить, и ущерб от 1 , может быть незначительным. Например, например, пакеты 1 могут быть не удалены должным образом, если вы попытаетесь удалить их; и обновления могут быть искажены, если обновление пытается обновить копию в «правильном» месте, но игнорирует копию в «неправильном» месте. Таким образом, если вышеперечисленные средства кажутся слишком радикальными или сложными, вы можете сойти с рук, оставив систему в этом состоянии.

Но если это важная система, я действительно бы ставку не на что.

Общее правило (опять-таки echoing @ basile-starynkevitch) - никогда не поддаваться мошенничеству /usr/bin, /binи друзья - они «принадлежат» к дистрибутиву - и пакет, который предлагает сделать это в рамках его обычной установки, ... не очень хороший пакет.

Изменить: Относительно пункта 3, в контексте systemd / Fedora и его друзей обсуждается, почему имеет смысл переместить все содержимое /binв /usr/bin, и символическую ссылку с первого на второе. Это не рекомендация делать это самостоятельно - эта страница адресована людям, которые делают рассылки - но она включает в себя некоторую историю того, почему существует это различие (и подразумевается, почему это теперь просто пыльная традиция).