Đã chuyển / nội dung bin sang / usr / bin, có thể hoàn tác?

Chạy Ubuntu 17.04, tôi đang cài đặt một phần mềm từ phân phối không lưu trữ, tôi phải chuyển nội dung bin -folder của phần mềm sang / usr / bin (đã là lời khuyên của iffy)

Đó là một trong những ngày đó, vì vậy những gì tôi đã làm thay thế:

mv /bin/* /usr/bin

Vì vậy, tôi đã làm rối và tôi vô tình di chuyển tất cả các tệp trong bin sang / usr / bin và / bin trống. Vì tôi coi / bin là hệ thống quan trọng, để khắc phục nhanh, tôi đã sao chép / usr / bin nội dung vào / bin.

Bây giờ nội dung của tôi / bin và / usr / bin giống hệt nhau và cả hai đều chứa các tệp ban đầu trong / bin và / usr / bin được phân tách.

1. Ubuntu của tôi hiện đang bị hỏng? (Chưa thử khởi động lại máy tính, ngay bây giờ mọi thứ dường như vẫn hoạt động)
2. Có cách nào để biết tập tin nào đã được di chuyển / sao chép vào / usr / bin gần đây nhất không, vì vậy tôi có thể tự xử lý tình huống này? 2.1 Thường có các tệp chồng lấp trong / bin và / usr / bin
3. Có cách nào khác để hoàn tác những gì tôi đã làm không?

Tôi chưa cài đặt Timeshift để khôi phục bản sao lưu không phải là một tùy chọn, nhưng hiện tại không có gì quan trọng trên máy tính, vì vậy tôi chỉ có thể thừa nhận để cài đặt lại toàn bộ phân vùng linux.

Ubuntu của tôi hiện đang bị hỏng?

Có, Ubuntu của bạn bị hỏng

Bạn đã làm hỏng một cái gì đó quan trọng để quản lý gói .

Vì vậy, trong thực tế, sao lưu dữ liệu quan trọng của bạn (ít nhất /etcvà /home), có lẽ cũng là danh sách các gói đã cài đặt, ví dụ như đầu ra dpkg -lvà cài đặt lại Ubuntu.

^{(một người không phải là người mới có thể cố gắng quản lý - như trong các câu trả lời khác - nhưng sau đó anh ta sẽ không mắc phải một lỗi lớn và cơ bản như vậy)}

Tôi chỉ có thể thừa nhận để cài đặt lại toàn bộ phân vùng linux.

Đó có lẽ là những gì sẽ tiêu tốn ít thời gian của bạn. Giữ cho hệ thống hiện tại của bạn với sự trợ giúp của các câu trả lời khác là giữ cho nó ở trạng thái rất lộn xộn (điều này sẽ khiến bạn đau đầu trong tương lai).

Vì bạn đang định dạng lại đĩa của mình, hãy xem xét đưa /homevào một phân vùng riêng (vì vậy những lỗi như vậy sẽ không làm mất dữ liệu của bạn). Trước khi thực hiện in trên giấy, đầu ra của df -hvà df -hivà fdisk -l(họ cung cấp thông tin về không gian đĩa -both được sử dụng và có sẵn- ...). Hãy khôn ngoan để có một phân vùng hệ thống đủ lớn (hệ thống tập tin gốc); nếu bạn có đủ khả năng thì 100 Gbyte là quá đủ.

Tôi đã phải chuyển nội dung bin -folder của phần mềm sang / usr / bin

(thuật ngữ: Unix có thư mục, không phải "thư mục").

Điều đó ( di chuyển đến /usr/bin/) là rất sai. Hoặc là cải thiện của bạn $ PATH (tốt nhất) hoặc nhiều nhất là add liên kết tượng trưng trong /usr/bin/và tốt nhất là di chuyển (hoặc thêm symlink) thực thi để /usr/local/bin/.

Cách tiếp cận khôn ngoan là không bao giờ thay đổi /usr/bin/, /bin, /sbin, /usr/sbin/ ngoài các công cụ quản lý gói (ví dụ dpkg, apt-get, aptitude, vv ...). Đọc FHS .

Trên Linux (và trên hầu hết các hệ thống khác, mặc dù POSIX không cung cấp cho bạn sự đảm bảo đó trừ khi di chuyển trên các hệ thống tệp), điều đó sẽ cập nhật thời gian của họ, vì vậy, giả sử không có bất kỳ hệ thống nào khác /usr/binbị chạm trong 24 giờ qua , bạn sẽ có thể di chuyển chúng trở lại với:

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

Loại bỏ echonếu điều đó có vẻ đúng. Lưu ý rằng bạn sẽ không thể khôi phục các tệp tồn tại cùng tên /binvà /usr/bin(những bản gốc trong /usr/binđó sẽ bị mất)

Một cảnh báo tiềm năng: nếu một số tệp được liên kết cứng trong cả hai /binvà /usr/bin, tất cả các liên kết cứng trong /usr/binsẽ được chuyển đến /bin.

Bây giờ, bạn có thể nghĩ rằng vì /binvà /usr/binnằm trong mặc định $PATHvà /bincó sẵn /bootít nhất là trước khi /usrđược gắn kết, nên việc thực thi có /binthay thế hay không /usr/bin.

Nhưng điều đó sẽ được xem xét rằng nhiều lệnh mã cứng các đường dẫn của các tệp thực thi và hy vọng chúng sẽ nằm trong một số trường hợp cụ thể. Một trường hợp phổ biến là cô ấy. Tất cả các tập lệnh có:

#! /usr/bin/env bash

sẽ không làm việc sau khi bạn làm mv /usr/bin/env /bin/env. Về vấn đề này, có các lệnh ở cả hai vị trí sẽ an toàn hơn ở chỗ nó sẽ không phá vỡ các tập lệnh đó.

1. Cài đặt của bạn nên chủ yếu là OK; không nên có các tệp khác nhau có cùng tên /usrvà /usr/bin(câu trả lời 2.1 của bạn), do đó, có tất cả các tệp trong cả hai /binvà /usr/binsẽ không phá vỡ bất cứ điều gì (cho đến khi bạn nâng cấp các gói). Vấn đề duy nhất bạn có thể có bây giờ là các liên kết tượng trưng bị hỏng, nếu bạn ghi đè lên một nhị phân bằng một liên kết tượng trưng cho nó. Để khắc phục điều này, hãy tìm các liên kết tượng trưng bị hỏng:

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

   và cài đặt lại bất kỳ gói nào tương ứng với các tệp được liệt kê (ví dụ: nếu /usr/bin/zshhiển thị là bị hỏng, dpkg -S /bin/zsh /usr/bin/zshsẽ cho bạn biết tệp đó đến từ gói nào; cài đặt lại với apt --reinstall install zsh).

2. Bạn có thể hiển thị và sắp xếp theo ctime để xem các tệp đã được thay đổi gần đây (sẽ bao gồm các tệp bạn đã di chuyển):

   ls -ltc /bin
   

3. Cách tiếp cận tốt nhất để hoàn tác những gì bạn đã làm là sử dụng cruftgói và xóa các tệp mà nó tìm thấy /binhoặc /usr/binkhông xuất phát từ gói:

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

   trừ khi các tệp là liên kết tượng trưng đến các tệp trong /etc/alternatives(trong trường hợp đó bạn nên để chúng một mình).

Nó có thể mang tính giáo dục để giải thích lý do tại sao hệ thống của bạn, ở mức độ lớn hơn hoặc thấp hơn, "bị hỏng".

1. Như @ basile-starynkevitch chỉ ra, hệ thống quản lý gói có khả năng bị lẫn lộn khủng khiếp nếu nó tìm thấy nhị phân /binkhi chúng nên ở /usr/binvà ngược lại.
2. Một số tập lệnh (có thể quan trọng) có thể khó kết nối để tìm một tệp nhị phân cụ thể trong thư mục này hoặc thư mục khác (trong một số trường hợp, đó là cách thực hành tốt, ví dụ từ quan điểm bảo mật, không dựa vào nội dung của $PATH).
3. Lý do tại sao có một sự khác biệt giữa /binvà /usr/binlà cái trước có khả năng nằm trên một phân vùng được gắn ở giai đoạn trước của khởi động. Trong ngữ cảnh này (nghĩa là khi khởi động hệ thống), không chỉ các /bin/xxxnhị phân có thể được gọi bằng một đường dẫn đầy đủ, mà thư mục /usr/bincó thể không có sẵn trên hệ thống tại thời điểm đó. (Nếu bạn df /binvà df /usr/bin, bạn có thể thấy cùng một hệ thống tệp được liệt kê hoặc các hệ thống khác nhau; có lẽ hầu hết các cài đặt mặc định, những ngày này, để cả hai thư mục trong cùng một phân vùng).

Vì vậy bạn có thể Gấp đôi thấy rằng, nếu bạn có cùng một mã nhị phân ở cả hai /binvà /usr/bin, sau đó vấn đề 2 và 3 sẽ không xảy ra, và những thiệt hại từ 1 có thể là nhỏ. Ví dụ, Re 1, các gói có thể không được gỡ cài đặt đúng cách nếu bạn cố xóa chúng; và các bản nâng cấp có thể bị cắt xén, nếu bản nâng cấp cố gắng nâng cấp bản sao ở vị trí 'chính xác', nhưng bỏ qua bản sao ở vị trí 'sai'. Do đó, nếu các biện pháp khắc phục ở trên có vẻ quá quyết liệt hoặc phức tạp, bạn có thể thoát khỏi hệ thống ở trạng thái này.

Nhưng nếu đây là một hệ thống quan trọng, tôi thực sự sẽ không ngân hàng về điều đó.

Một quy tắc chung (một lần nữa lặp lại @ Basile-starynkevitch) là không bao giờ để con khỉ với /usr/bin, /binvà bạn bè - họ 'thuộc về' sự phân bố - và một gói phần mềm mà đề nghị làm như vậy như là một phần bình thường của nó cài đặt là ... không phải là một gói tốt.

Chỉnh sửa: Có liên quan đến điểm 3, có một cuộc thảo luận trong bối cảnh systemd / Fedora và bạn bè về lý do tại sao việc chuyển tất cả nội dung /binsang /usr/binvà liên kết từ đầu đến thứ hai lại hợp lý. Đây không phải là một đề xuất mà bạn tự làm điều này - trang đó được gửi đến những người thực hiện phân phối - nhưng nó bao gồm một số lịch sử về lý do tại sao sự khác biệt này tồn tại (và bằng ngụ ý tại sao bây giờ chỉ là truyền thống bụi bặm).