Komut satırını kullanarak Time Machine dosyalarını nasıl silebilirim


68

Zaman Makinesi Bölümündeki bazı dosyaları / dizinleri rm kullanarak silmek istiyorum , ancak yapamıyorum. Sorunun, yedekleme dosyalarındaki bir dizi erişim denetimi genişletilmiş özniteliği ile ilgili olduğundan eminim, ancak rm'nin çalışması için bunların nasıl geçersiz kılındığını / devre dışı bırakılacağını bilmiyorum . Aldığım hata örneği:

% sudo rm -rf Backups.backupdb/MacBook/Latest/MacBook/somedir
rm: Backups.backupdb/MacBook/Latest/MacBook/somedir: Directory not empty
rm: Backups.backupdb/MacBook/Latest/MacBook/somedir/somefile: Operation not permitted

Bunun için Time Machine GUI veya Finder'ı kullanmak istemememin birkaç nedeni var. Mümkünse, tüm diğer dosyalar için genişletilmiş korumayı sürdürmek isterim (İşimi yaptıktan sonra yeniden etkinleştiremezsem, onları genel olarak devre dışı bırakmak istemem).


Yaklaştım. İlk olarak, Time Machine diskimdeki ACL'leri devre dışı bırakmam gerekiyordu. Önceden, bunu yapmak için fsaclctl kullanılır, ancak Snow Leopard bunu içermez. Ben OSX'in eski bir sürümünden binary kopyasını aldım ve şunu koştum:% sudo fsaclctl -p / Volumes / tmvol -d Daha sonra bir dizini silmek için "sudo rm -rf" kullanmaya çalıştım, ancak hala sorunlarla karşılaştım. bazı dosyalar (diğerleri iyi gitti ama). Özellikle, yumuşak bağlantılarda başarısız oldu. Çok ilginç. Artı tarafta, bağlantılar neredeyse hiç yer kaplamaz. Olumsuz tarafta, hala etrafta dolaşan dizinler var.
Tim,

Anlık görüntüleri veya anlık görüntüdeki klasörleri silerken kabul ettiğiniz yanıtın oldukça tehlikeli olduğu anlaşılıyor rm -r Backups.backupdb/MacBook/Latest/MacBook/somedir; Kabul edersen, lütfen Arne'in cevabını kabul et.
Arjan

Yanıtlar:


115

"İşleme izin verilmedi" hataları etrafında çalışmak için, Time Machine Safety Net "bypass" programını kullanın:

sudo /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass rm -rfv /Volumes/[disk]/Backups.backupdb/[path]

10.8 Mountain Lion'da bypass 'Helpers'a taşındı:

/System/Library/Extensions/TMSafetyNet.kext/Helpers/bypass

10.10'da Yosemite, bypass buraya taşındı:

/System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass

Belirli fotoğrafları silmek için bunu kullanırken dikkatli olun : Time Machine sert bağlantılar kullandığından rm -r, klasörlerde kullanmak aynı makinenin daha eski ve daha yeni anlık görüntülerini de etkileyebilir . ( tmutil deleteBelirli bir anlık görüntüyü güvenli bir şekilde silmek için verilen diğer yanıtlara bakın .) Tek bir makinenin tüm anlık görüntülerini rmsilmeyi kullanmak tamam. Ve böylece kullanıyor olarak o zaman aslında dosyayı kaldırmak istediğiniz bir sabit bağlı dizinine varsayarak, sadece belirttiğiniz anlık (ler) den o kadar da zor bağlantılı dosyayı kaldırır belirli bir dosyayı silmek için değil bütün bu sıkı bağlı dizinler.rm


+1 !! Bu bana yardımcı oldu. Diğerlerini bile denemedim, çünkü bu “doğru yol” gibi görünüyordu ve gerçekten de konuyu başka soru sormadan çözmeme izin verdi. Teşekkürler!
üçlü

Sadece + 1'lemek için bir hesap oluşturdum. Bunun için daha iyi bir çözüm arıyordum ve bu buydu. Beni deli ediyordu. Teşekkür ederim.
CWSpear

3
Muhteşem. Bu çalışıyor. (birkaç yüz bin dosyanın her birinin girişini görmekten kaçınmak için 'v' seçeneğini dışarıda bırakmama rağmen) yani:sudo ...bypass rm -rf /Volumes/...
Brent Faust

6
Bu Time Machine dosyalarını yönetmek için son derece tehlikeli bir yöntemdir; Time Machine, önceki yedeklemeden bu yana değişmeyen klasörlere başvuruda bulunmak için sabit bağlanmış dizinler kullanır, ancak rmişlem bunları anlamaz ve bu bağlantıları izler ve dosyaları onlardan kaldırır. Bu, seçtiğinizden daha eski ve daha yeni yedeklemelerdeki dosyaları silebileceğiniz ve potansiyel olarak yedekleme (ler) üzerinde onarılamayacak bir hasara neden olabileceğiniz anlamına gelir. Arne Stenström'ün kullanım önerisi tmutilbugüne kadar üstün bir çözümdür.
Haravikk

1
Haravikk yorumuyla ilgili biraz uzatmak için: kullanarak rmsabit bağlı için dosyalar tamam, ama sabit bağlı için klasörler değil. Kent'in cevabı aynı problemden bahsediyor. Ve OS X'de bir dizine bir hardlink oluşturmak için Unix komutu nedir? Birisi 2010 yılında 10.5 yazdı: "Silme farklı bir hikaye: dizinleri silmenin genel yolunu izlerseniz, içeriği silersiniz. Bu nedenle dizini" bağlantısını kaldırmanız gerekir: unlink new_hard_link". Bu nedenle, yalnızca belirli bir makinenin tüm yedeklemelerini (anlık görüntüleri) silmek için kullanın .
Arjan

26

BLUF (önden alt satırda):

sudo tmutil delete snapshot-dir


Kullanılması Zaman Makinesi'nin dosya ve klasörleri çalışmayan bir klasör hiyerarşisinin tüm ACL kaldırmak için Backups.backupdb nedeniyle, TM Güvenlik Ağı mekanizması ve bu anlatılan kriterler 318 Teknik Dergisi yazı (ama muhtemelen tam olarak anlatıldığı gibi) .     (Bunu öğrenmeden önce, Eric W'in cevabında bahsi geçen Güvenlik Ağı'nı ararken (hangi işe yaradıysa ), sadece bir TM yedeklemesinin alt klasöründen klonlanmış bir klasör üzerinde test ettim ve chmod çalıştı. Ama chmod'u gerçek bir klasörde denemek TM yedekleme "İşleme izin verilmedi" hatası veriyor.)sudo chmod -R -N folder

Olası kullanım:
    Mac OS 10.7+ 'de, hala Snow Leopard'da olduğum için bir deneme komutu var (denemedim). Bu bir var silme açıklamasına göre fiil, "tarafından yapılan görmemiş veya mevcut makine tarafından talep edilmedi yedeklerden anlık silebilirsiniz" (bir "anlık" tek aşamalı yedekleme temsil eden bir tarihli klasörü) bulunmaktadır. Bu da demektir eğer bana belli değil olamaz anlık silmek edilir akım makine tarafından yapılan veya iddia etti. (?)


2
Nitekim, tmutil kullanışlıdır ve yedekleri silmenize izin verir ( tmutil delete /Volumes/DISK/Backups.backupdb/HOST/DATE_FOLDER). Ancak, yine de "Backups.backupdb" klasörünün kendisini silmek için Eric'in bypass numarasına ihtiyacınız var.
mivk

Benim OSX 10.8.3 (Dağ Aslanı) bypass gerektirmedi. Sadece sudo tmutil delete <snapshot-dir>. Popüler bypass rmcevap modası geçmiş.
John Mee

tmutilAnlık görüntüden yalnızca bazı dosyaları silmek mümkün mü ? Benim için işe yaramadı ( Invalid deletion target (error 22)) bu yüzden onunla gittim bypass.
Robert Tupelo-Schneck

BLUF için +1. Bunu (tamamen etkileyici) Yönetici-Araçlar'dan aldınız mı? :)
Olie

Ayrıca: Backups.backupdbYedek diskimde (Time Capsule) görmediğim bir dizine referans bulmaya devam ediyorum. Sadece formun bir şeyleri var MachineName.sparsebundle. Format değişti mi? TM'nin delete backup komutunu kullanmaya çalışıyorum, ancak birkaç saatliğine% 99,99 ilerleme çubuğunda kaldı.
Olie,

12

bypassEski bir yedeklemeyi kaldırmak için bu komutu kullanma hakkında bir uyarı : Silinen yedeklemenin önceki veya sonraki yedeklemelerde tamamen aynı klasörleri varsa, dosyalar daha önceki veya sonraki yedeklemelerden de silinmiş olabilir !

Time Machine, yalnızca değişmemiş dosyalar için sabit bağlantılar kullanmakla kalmaz, aynı zamanda hiçbir dosya eklenmemiş, değiştirilmemiş veya silinmemiş klasörler için de sert bağlantılar kullanır. Bu gibi bir şeyle sonuçlanır:

/2014-11-06/folder/file1
                  /file2
                  /file3
/2014-11-13/folder/file1 = hard link to file /2014-11-06/folder/file1
                  /file2 (changed; new inode)
                  /file3 = hard link to file /2014-11-06/folder/file3
/2014-11-20/folder/ = hard link to folder /2014-11-13/folder/
/2014-11-27/folder/ = hard link to folder /2014-11-20/folder/

Yukarıdakilerle, herhangi bir dosyayı silme işlemi /2014-11-06/folder/iyidir ve yalnızca o tarih için yedeklemeyi etkiler. Sabit link referans sayıları azaltılır, bu nedenle " inode " for file2silinir, ancak sonraki inodlar nedeniyle inode 1 olan file1ve file3hala bir referans sayımı 1 olur. Bu yüzden rm -R /2014-11-06de iyi.

Ancak, her iki herhangi bir dosyayı çıkarmadan /2014-11-13/folder/, /2014-11-20/folder/ya /2014-11-27/folder/etkin bir bütün o 3 klasörlerden kaldıracaktır.

Sorun şu ki rm -R, sabit bağlantılı klasörler umrunda değil. Sadece bulduğu herhangi bir hard-link klasöre geri alır, tüm dosyalarını cesaretle siler ve sonra boş klasörü kaldırır.

Öyleyse: eski bir yedeği kaldırırken, sabit bir klasöre tekrarlama yapılmamalı ve içeriği silinmemelidir. Bunun yerine, yalnızca klasörün kendisi için olan sabit bağlantı kaldırılmalıdır . Yani, Arne'nin cevabında açıklandığı gibi rm -Rkullanmak yerine .tmutil delete

Bir kenara, OS X unlinkkomutunun klasörler üzerinde kullanılamayacağı görülüyor : "bir dizin olmamalıdır, sadece bir argüman sağlanabilir" . OS X API, sabit bağlı klasörleri kaldırabilir ve GNU Coreutils , Homebrew kullanılarak yüklenenler gibi de olabilir .

Son olarak, yukarıdakilerin hepsini kanıtlamak için bir test vakası (OSX 10.6.8):

sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist 
-rw-r--r--@ 2 USERNAME  staff  1551 10 30  2014 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME  staff  1551 10 30  2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME  staff  1551 10 30  2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME  staff  1551 10 30  2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist

Her olay için bağlantı sayısının 2 (ikinci sütun) olduğunu unutmayın. İlk oluşumu kaldıralım:

sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist 
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist 
-rw-r--r--@ 1 USERNAME  staff  1551 10 30  2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME  staff  1551 10 30  2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME  staff  1551 10 30  2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist

Bu nedenle, dosyalardan birinin bağlantısını kaldırdıktan sonra, dosya yine de 3 kez gösterilse de, bağlantıların sayısı her seferinde 1'e düşmüştür. Henüz bir sorun yok. İlk oluşumu tekrar kaldırın:

sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist 
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist 
ls: 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist: No such file or directory

Şimdi hepsi gitti. Görünüşe göre, dosya TopSites.plisten son 2014-11-06 değiştirildi ve 2014-11-13 tarihinde çok bağlantılıydı; o sırada bazı dosyalar da Safariklasöre eklendi, değiştirildi veya kaldırıldı . Daha sonra, Safariklasörün içeriği sonraki iki yedeklemede değişmedi, bu nedenle 2014-11-20 ve 2014-11-27'de Safariklasör önceki yedeklemeye zor bağlandı.

Aslında, 4 klasör yalnızca 2 düğüm kullanır (ilk sütun):

sh-3.2# ls -lFaid 2014-11*/Users/USERNAME/Library/Safari/
648651968 drwxr-xr-x@ 86 USERNAME  staff  2924  9 10 16:06 2014-11-06-012454/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME  staff  2924  9 10 16:07 2014-11-13-024438/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME  staff  2924  9 10 16:07 2014-11-20-014044/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME  staff  2924  9 10 16:07 2014-11-27-025033/Users/USERNAME/Library/Safari//

1
Bazı arka plan: dosyalar için sabit bağlantılar beklendiği gibi çalışır; yalnızca silmek istediğiniz sabit bağlantı kaldırılır. Beğen: touch file1; ln file1 file2; ln file2 file3; ls -li; rm file2; ls -liyalnızca tek bir sabit bağlantıyı kaldıracak. Ancak klasörler için , OS X'te bir dizine hardlink oluşturmak için Unix komutu nedir? Birisi 2010 yılında 10.5 yazdı: "Silme farklı bir hikaye: dizinleri silmenin genel yolunu izlerseniz, içeriği silersiniz. Bu yüzden dizini" bağlantılandırmanız gerekir ": unlink new_hard_link". Bu muhtemelen hala geçerli.
Arjan

Man sayfası unlink(10.6.8 olarak) o dizinlerde kullanılamaz söylüyor: When the utility is called as unlink, only one argument, which must not be a directory, may be supplied.
Kent,

Hmmm, gizem. Daha da ötesi, cevabınız önemlidir: [bypass] rm -rbağlı dizinler üzerinde kullanmayın . (Ama bunu size açıklamak zorunda değilim.)
Arjan

Sadece biraz daha denedim. Koşmak bypass unlink FILE, aynı (istenmeyen?) Sonuçlarla aynıdır bypass rm FILE. Aynı DOSYA, yalnızca belirtilen konumdan değil, tüm yedeklemelerden kaldırılır. Ve unlinkbağımsız değişken olarak bir dizini veya birden fazla dosyayı almayacak (10.6.8 sunucusu; fakat bunun yeni işletim sistemi sürümleri arasında değişeceğini sanmıyorum)
Kent

Vay be, ben tarafından oldukça şaşırdım senin bypass rm FILEve bypass unlink FILEtek için gördüklerini eşleşmeyen tüm özdeş dosyaları, kaldırma touch file1; ln file1 file2; ln file2 file3; ls -li; unlink file2; ls -li, ne için touch file1; ln file1 file2; ln file2 file3; ls -li; /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass unlink file2; ls -li. Asla bir yedeklemeden bir şey çıkarmayacağım ...
Arjan

3

Not: Eric W tarafından belirtilen "TM Güvenlik Ağı" nedeniyle, bu cevap, sorunun özellikle ilgili olduğu bir Time Machine yedeklemesi için işe yaramaz. Ancak diğer her durumda, ACL'lerden nasıl kurtulacağınızla ilgili bilgiler önemlidir.


Eski bir işletim sisteminden kopyalanan ACL araçlarını kullanmanıza gerek yoktur.

Kullanım ls -leEKL'lerini görüntülemek ve chmodbunları değiştirmek için.

Daha fazla bilgi için, man chmod"ACL Manipulation Options" bölümüne bakınız.

Tüm ACL'leri bir klasör hiyerarşisinden kaldırma komutu:

chmod -R -N foldername

2

Zaman makinesi rshapshot gibi çalışır. Her yeni yedek için bir sabit bağlantılar ağacı oluşturur. Zaten önceki bir yedeklemede varolan dosyalara yapılan zor bağlantılar çok az ek alan kullanır. Yalnızca bir dosyaya yapılan son bağlantı kaldırıldığında, dosya gerçekten dosya sisteminden silinir.

Bireysel yedeklemenin tamamını kaldırmaktan zarar gelmez. Sadece zor bağlantıları kaldırıyorsunuz. Başka hiçbir yedekleme etkilenmeyecektir. Ancak bu tmutil ile yapılabilir.

Korumayı atlamanın gerekli olabileceği bir senaryo, belirli bir dosyayı tüm yedeklemelerden kaldırmaktır (ve bu yazıya neden katılmamın nedeni).

Yedek diskim dolu. Aylardır yedeklenmiş çok büyük bir dosya (gigabayt) var. Bir fiziksel kopyası var, ancak bu kopyaya sabit bağlantılar içeren birçok anlık görüntü var. Aslında bu dosyadan kurtulmak için her bağlantıdaki sabit bağlantıyı kaldırmam gerekiyor.

Inode numarasının, aynı dosyaya tüm linkler için aynı olduğunu unutmayın.

% cd /Volumes/WD\ 500G\ USB/Backups.backupdb/csm-laptop
% ls -li */Macintosh\ HD/Users/csm/vm.img
...
2740350 -rw-r--r--@ 28 csm  staff  42949672960 Feb 17 16:12 2015-05-08-005636/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm  staff  42949672960 Feb 17 16:12 2015-05-08-015812/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm  staff  42949672960 Feb 17 16:12 2015-05-08-030036/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm  staff  42949672960 Feb 17 16:12 2015-05-08-041307/Macintosh HD/Users/csm/vm.img
2740350 -rw-r--r--@ 28 csm  staff  42949672960 Feb 17 16:12 Latest/Macintosh HD/Users/csm/vm.img

(En son dizinin son tarihli dizine bir bağlantıdır)

% sudo bypass rm -f */Macintosh\ HD\Users\csm\vm.img

Dosya tüm yedeklemelerden kaldırılır ve alan döndürülür. Dosya zaman içinde değişiyorsa, her yedek tam bir kopyaya sahip olacak ve geri gönderilen alan çok büyük olacaktır.


Gelince "zarar vermez bütün bir birey yedeğini kaldırılıyor. Sadece sabit bağlantıları kaldırıyoruz. Başka hiçbir yedekleme etkilenecektir." Bu işaret ederse enstantane tek makine için yedekleme dahilinde, daha sonra verilen Kent'in (eski) cevabı kullanılarak rm -rtehlikeli: (olmuş ya) olabilir. Üzgün ​​olmaktan daha güvenli ol ve tmutilbunun için kullan .
Arjan

0

Komutu, yedeğin "sahibi" kullanıcı olarak yürütmüyorsanız, komut satırından silmeniz zor olacaktır. Bu sorunla ilgili yeni bir geçiş yaşadım ve tüm Time Machine yedeklemesini (1tb +) ayırıp, herhangi bir erişim elde etmeden önce sürücüyü biçimlendirmek zorunda kaldık - ve bana güven, izinleri geçersiz kılmak için her şeyi denedim.


2
sudo bana yönetici olarak çalıştırdığım tüm dosyalara erişim izni vermeli. Bunun bir ACL sorunu olduğundan eminim ve bunun üzerinde çalışıyorum.
Tim

1
Nic, birkaç yıl gecikti, ama kaçırdıysanız: Eric'in cevabını görün .
Arjan

@Tim: Bu iddia, değişmez nitelik ( chattr) verildiğinde, diğer unixoid sistemlerinde bile doğru değildir . Kök teorik olarak size verecek olan herhangi bir güvenlik ağını atlatmaktır .
0xC0000022L

0

Bir klasördeki tüm dosyaları değil, yalnızca belirli dosyaları silmek istiyorsanız, klasörü Time Machine'nin dışlama listesine ekleyerek bunu başarabilirsiniz. (Sistem tercihleri ​​-> Zaman Makinesi -> Seçenekler. Klasörü buraya sürükleyin.)

Bir dahaki sefere yedekleme yaptığınızda, bu klasörün kopyaları önceki yedeklemelerden kaldırılır.

Şimdi, bunu gerçekten bir CLI'den yapmak istiyorsanız, biraz hantal da olsa bir yol var.

  1. /Library/Preferences/com.apple.TimeMachine.plist dosyasının bir yedeğini alın
  2. /Library/Preferences/com.apple.TimeMachine.plist dosyasını, bununla oynayabileceğiniz bir yere kopyalayın.
  3. Cd'yi nereye koyduğunuza yerleştirin.

  4. plutil -convert xml1 com.apple.TimeMachine.plist
    İkili formdan dönüştürmek için yürütün .
  5. Dönüştürülen pisti tercih edilen metin editöründe açın, "atlamak" için arama yapın
  6. Bu bölüme, olarak biçimlendirilmiş yeni bir satır ekleyin. <string>/Path/To/Exclude</string>
  7. Kaydet ve çık, yürüterek geri dönüştür
    plutil -convert binary1 com.apple.TimeMachine.plist
  8. Düzenlenmiş dilinizi tekrar / Library / Preferences / dizinine kopyalayın
  9. Yürüterek bir yedekleme başlatın
    /System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper -auto

Düzenleme: 9. adımı gerçekleştirdiğinizde, yeni dışlanan klasörün tüm kopyaları önceki yedeklemelerden silinir.

İstisnayı kaldırmak için, yedeğinizi tekrar / Library / Preferences içine kopyalayın.


Bir dizini dışlamaya çalışmıyorum. Bir dizini varolan bir yedekten silmeye ve bazılarını komut satırından yapmaya çalışıyorum. Gerçekten, rm'nin bir Backups.backupdb dizini içerisinde çalışmasına nasıl izin verileceğini bulmak istiyorum.
Tim

Tamam, belki de yukarıdaki adımları uygularken, klasörün yedeklemelerden gerçekten silindiği konusunda talimatlarım net değildi. Düzenlemeye bak. Ancak, aradığınız çözüm değilse, o zaman her zaman su - rootve sonra rm -rfklasörleri yapabileceğinizi varsayalım , ancak bu şekilde yedeklemeler kadar değerli bir şeyle uğraşmanın genellikle kaçınmaya çalışılması gereken bir şey olduğunu düşünüyorum.
Frost,

Ancak bir dışlama olarak eklemek, tüm kopyalarını tüm yedeklemelerden siler. Ayrıca, bu bir TimeMachine yedeği olsa da, bu çalışmayı yaptığım makineden değil, artık aktif bir TimeMachine değil. sudo "su - root" ve sonra "rm -rf" ile aynı etkiye sahiptir. Bunun başarısız olduğuna eminim, çünkü Apple dosya sistemine * nix izinlerinin ötesinde bir güvenlik düzeyi ekledi.
Tim

Bu aptalca gelebilir, ancak bir mac üzerinde sudoaynı etkiye sahip olduğundan tam olarak emin değilim su - root. Yeterli olmayan bir şeyi silmeye çalıştığım bir anı hatırlıyor sudogibiyim ama sudo - roothile yaptım.
Frost,

3
@ Frost- Time Machine'in önerdiğiniz şekilde çalıştığını sanmıyorum. Bir klasörü hariç tutup, TM'yi çalıştırmayı denedim ve bu klasörün eski yedeklemeleri hala TM'de mevcut. Ya da belki de davranışı, neredeyse bir yıl önce yayınladığınızdan bu yana değişti.
Kafein Koma

0

Sen yapabilir lskullanarak uzun görünümde liste uzatılabilir özelliklerini -@bayrağı. -eBayrak sağladığınızda ACL'leri listeler . Böylece, neyle uğraştığınızı öğrenebilirsiniz ls -lea@ DIR.

Yerel Time Machine yedeklerime göre, Time Machine en yeni ve en eski anlık görüntüler hakkında meta veriler içeren genişletilmiş özellikler uygulamaktadır. Xattr'ler tarafından depolanan veriler ikili bir düzlem olarak görünüyor. Bunlar zararsız görünüyor.

Time Machine ayrıca ACL'leri standart bir kullanıcı dizinine yerleştirilenler gibi bildiği bazı dizinlere de uygulamaktadır. Yolunuzda potansiyel olarak duran iki tür ACL vardır: doğrudan silmeyi reddeden dosyaya veya dizine uygulananlar ve delete_child'i reddeden dosyanın üst kısmına uygulananlar.

Ne yazık ki, Mac OS X, ACL'leri görüntülemek ve işlemek için kullanıcı yardımcı programlarını sağlamaz getfaclve setfaclPOSIX.2c tarafından belirtilir. ACL'lerle uğraşmak için biraz programlama yapmanız gerekir; acl(3)man sayfasına bakınız .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.