/ Bin içeriği / usr / bin klasörüne taşındı, geri alınabilir mi?

Ubuntu 17.04'ü çalıştırırken, depo olmayan dağıtımdan bir yazılım yüklüyordum, yazılım kutusu klasör klasörlerini / usr / bin'e (zaten iffy tavsiyesiydi) taşımam gerekiyordu

O günlerden biri, onun yerine ne yaptım:

mv /bin/* /usr/bin

Bu yüzden berbat ettim ve yanlışlıkla bin içindeki tüm dosyaları / usr / bin'e taşıdım ve / bin boştu. Ben / bin sistem açısından kritik olduğundan, hızlı çözüm için, / usr / bin içeriğini / bin dizinine kopyaladım.

Şimdi / bin ve / usr / bin içerikleri aynı ve her ikisi de orijinal olarak / bin ve / usr / bin içindeki dosyaları ayrılmış olarak içeriyor.

1. Ubuntu'm şimdi bozuk durumda mı? (Bilgisayarı yeniden başlatmayı denemedim, şu anda her şey hala çalışıyor gibi görünüyor)
2. En son hangi dosyaların / usr / bin klasörüne taşındığını / kopyalandığını bilmenin bir yolu var mı, bu yüzden durumu manuel olarak halledebilir miyim? 2.1 / bin ve / usr / bin dosyalarında genellikle çakışan dosyalar var mı?
3. Yaptığım şeyi geri almanın başka yolları var mı?

Timeshift'in yüklü olmadığı için yedekleri geri yüklemek bir seçenek değil, ancak şu anda bilgisayarda kritik bir şey yok, bu yüzden sadece tüm linux bölümünü yeniden yüklemeyi kabul edebilirim.

Ubuntu'm şimdi bozuk durumda mı?

Evet, Ubuntu'nuz bozuldu

Paket yönetimi için önemli bir şey berbat ettiniz .

Bu yüzden pratikte, önemli verilerinizi (en azından /etcve /home), belki de kurulu paketlerin listesini, örneğin çıktısını alın dpkg -lve Ubuntu'yu yeniden yükleyin.

^{(acemi olmayan bir kişi - diğer cevaplardaki gibi - yönetmeye çalışabilir, ancak o zaman böyle büyük ve temel bir hata yapmazdı)}

Tüm linux bölümünü yeniden yüklemeyi itiraf edebilirim.

Muhtemelen zamanınızı daha az tüketen budur. Mevcut sisteminizi diğer cevapların yardımıyla tutmak, çok dağınık bir durumda tutmaktır (bu da size gelecekteki baş ağrılarını verecektir).

Diskinizi yeniden biçimlendirdiğiniz için, /homeayrı bir bölüm oluşturmayı düşünün (böylece ileride bu tür hatalar verilerinizi kaybetmez). Bu baskıyı kağıt üzerinde yapmadan önce df -hve df -hive çıktıları ( hem fdisk -lkullanılan hem de kullanılabilir olan disk alanı hakkında bilgi verir ...). Yeterince büyük bir sistem bölümüne sahip olun (kök dosya sistemi); Ödeyebiliyorsanız 100 Gbayt fazlasıyla yeterli.

Bin yazılım klasörü içeriğini / usr / bin klasörüne taşımam gerekiyordu

(terminoloji: Unix'te "klasörler" değil, dizinler bulunur).

Yani ( hareketli için /usr/bin/) çok yanlış. Ya geliştirmek $ PATH Çoğu eklentide (tercihen) veya sembolik içinde /usr/bin/ve tercihen hareket (veya sembolik ekleyin) için yürütülebilir /usr/local/bin/.

Bilge yaklaşım asla değişiklik etmektir /usr/bin/, /bin, /sbin, /usr/sbin/ paket yönetim araçları dışında (örneğin dpkg, apt-get, aptitude, vs ...). FHS'yi okuyun .

Linux'ta (ve diğer sistemlerin çoğunda, POSIX, taşıma dosya sistemleri arasında olmadığı sürece size bu garantiyi vermese de), ctime'larını güncelleyecektir, bu nedenle /usr/binson 24 saat içinde diğerlerinden hiçbirine dokunulmadığı varsayılarak , bunları aşağıdakilerle geri taşıyabilmeniz gerekir:

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

echoDoğru görünüyorsa çıkarın . Ve içinde aynı adla bulunan dosyaları kurtaramayacağınızı /binve /usr/bin(içinde orijinal olanlar /usr/binkaybolacağını) unutmayın.

Potansiyel bir uyarı: bazı dosyalar her ikisinde de sabit bağlı olsaydı /binve içindeki /usr/bintüm sabit bağlantılar /usr/bintaşındıysa /bin.

Şimdi, çünkü düşünebilir /binve /usr/binvarsayılan içindedir $PATHve /bingeçerli /bootönce en az /usrmonte edilir, bu yürütülebilir olan olmamalıdır meselesi olmadığını /binyerine /usr/bin.

Ancak bu, birçok komutun yürütülebilir dosyaların yollarını kodladığını ve belirli bir durumda olmasını beklediğini göz ardı eder. Yaygın bir durum, patlamalardır. Aşağıdaki tüm komut dosyaları:

#! /usr/bin/env bash

yaptıktan sonra çalışmaz mv /usr/bin/env /bin/env. Bu bakımdan, her iki konumda komutlara sahip olmak, bu komut dosyalarını bozmaması açısından daha güvenlidir.

1. Kurulumunuz çoğunlukla iyi olmalıdır; içinde aynı adda /usrve /usr/bin(2.1'inize cevap veren) farklı dosyalar olmamalıdır , bu nedenle tüm dosyaların her ikisine de sahip olması /binve /usr/binhiçbir şey kırmaz (paketleri yükseltinceye kadar). Şimdi sahip olabileceğiniz tek sorun, sembolik bir ikilinin üzerine yazdıysanız bozuk sembolik bağlantılardır. Bunu düzeltmek için bozuk sembollere bakın:

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

   ve listelenen dosyalara karşılık gelen paketleri yeniden yükleyin (örneğin, /usr/bin/zshbozuk olarak görünüyorsa, dpkg -S /bin/zsh /usr/bin/zshdosyanın hangi paketten geldiğini size söyleyecektir; yeniden yükleyin apt --reinstall install zsh).

2. Yakın zamanda değiştirilen dosyaları (taşıdığınız dosyaları içerecek) görmek için ctime'a göre gösterebilir ve sıralayabilirsiniz:

   ls -ltc /bin
   

3. Yaptığınız işlemi geri almak için en iyi yaklaşım, cruftpaketi kullanmak ve bulduğu /binveya /usr/binbir paketten gelmeyen dosyaları silmektir :

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

   dosyalar içindeki dosyalar için sembolik link olmadıkça /etc/alternatives(bu durumda onları yalnız bırakmalısınız).

Sadece ayrıntılı eğitim olabilir neden senin sistemdir, 'kırık' az veya çok ölçüde.

1. @ Basile-starynkevitch'in de belirttiği gibi, paket yönetim sistemi, /binne zaman bulunmaları gerektiğinde ikili dosyalar bulursa çok karışık bir şekilde karışma potansiyeline sahiptir /usr/bin.
2. Bazı (muhtemelen önemli) komut dosyaları, bir dizinde veya diğerinde belirli bir ikili dosya bulmak için kablolu olabilir (bazı durumlarda, örneğin güvenlik açısından, değil içeriğine güvenmek $PATH).
3. Orada arasında bir ayrım olmasının sebebi /binve /usr/bineski potansiyel çizme önceki bir aşamada monte edilir bir bölüme olabileceğidir. Bu bağlamda (yani, sistem önyüklenirken), /bin/xxxikili dosyalara yalnızca tam bir yolla atıfta bulunulmaz, aynı zamanda dizin /usr/binbu noktada sistemde bulunmayabilir. (Siz df /binve df /usr/bin, listelenen aynı dosya sistemini veya farklı olanları görebilirsiniz; muhtemelen varsayılan yüklemelerin çoğu, bu günlerde, her iki dizini de aynı bölümde bırakın).

Böylece , her ikisinde de aynı ikili dosyalara sahipseniz,/bin ve /usr/binsorun 2 ve 3'ün meydana gelmeyeceğini ve 1'den gelen hasarın küçük olabileceğini . Re 1, örneğin, paketleri kaldırmaya çalışırsanız düzgün şekilde kaldırılmayabilir; ve yükseltme kopyayı 'doğru' yerde yükseltmeye çalışırsa, ancak kopyayı 'yanlış' yerde yoksayarsa yükseltmeler bozulabilir. Yukarıdaki ilaçlar çok şiddetli veya komplike görünüyor Dolayısıyla, eğer sen olabilir bu durumda sistemin bırakarak kaçtı.

Ama bu önemli bir sistemse, gerçekten buna güvenmem.

Genel bir kural (tekrar @ basile-starynkevitch'in yankılanması) asla maymunla /usr/bin , /binve arkadaşları - ve bir ... değil iyi bir paket yüklemek normal bir parçası olarak bunu yaparken önerir bir paket - onlar dağıtımına 'aittir'.

Düzenleme: İlgili 3 işaret etmek, orada var systemd / Fedora ve arkadaş bağlamında tartışma o tüm içeriğini taşımak için mantıklı neden /biniçin /usr/binkapatıldığı ikinci ve sembolik olarak bağlayacaktır. Bu, bunu kendiniz yaptığınız bir öneri değildir - bu sayfa dağıtım yapan kişilere yöneliktir - ancak bu ayrımın neden var olduğuna dair bazı geçmişleri içerir (ve bunun neden artık sadece tozlu gelenek olduğu anlamına gelir).