Mengapa tautan keras ke direktori tidak diizinkan di UNIX / Linux?


130

Saya membaca di buku teks bahwa Unix / Linux tidak mengizinkan tautan keras ke direktori tetapi mengizinkan tautan lunak. Apakah karena, ketika kita memiliki siklus dan jika kita membuat tautan keras, dan setelah beberapa waktu kita menghapus file asli, itu akan menunjuk ke beberapa nilai sampah?

Jika siklus adalah satu-satunya alasan di balik tidak memungkinkan tautan keras, lalu mengapa tautan lunak ke direktori diizinkan?


2
Di mana harus ..menunjuk? Terutama setelah menghapus tautan keras ke direktori ini, di direktori yang ditunjuk oleh ..? Perlu menunjuk ke suatu tempat.
Thorbjørn Ravn Andersen

2
..tidak perlu ada secara fisik di drive apa pun. Ini adalah tugas sistem operasi untuk melacak direktori kerja saat ini, jadi, seharusnya relatif sederhana untuk juga menyimpan daftar inode yang terkait dengan setiap proses 'cwd dan merujuk ke itu ketika melihat penggunaan ... Tentu saja, itu berarti symlink perlu dibuat dengan mempertimbangkan hal itu, tetapi Anda harus berhati-hati untuk tidak merusak symlink, dan saya tidak berpikir bahwa aturan tambahan akan membuat mereka tidak berguna.
Parthian Shot

Saya suka penjelasan ini . Ringkas dan mudah dibaca dan / atau skim.
Trevor Boyd Smith

Jawaban:


143

Ini hanya ide yang buruk, karena tidak ada cara untuk membedakan antara tautan keras dan nama asli.

Mengizinkan tautan keras ke direktori akan memecah struktur grafik asiklik yang diarahkan pada sistem file, mungkin membuat loop direktori dan menggantung sub direktori direktori, yang akan membuat fsckdan file tree walker lainnya rentan kesalahan.

Pertama, untuk memahami ini, mari kita bicara tentang inode. Data dalam sistem file disimpan dalam blok di disk, dan blok-blok itu dikumpulkan bersama oleh sebuah inode. Anda dapat menganggap inode sebagai THE file. Inode tidak memiliki nama file. Di situlah tautan masuk.

Tautan hanyalah penunjuk ke inode. Direktori adalah inode yang menyimpan tautan. Setiap nama file dalam direktori hanyalah tautan ke inode. Membuka file di Unix juga membuat tautan, tetapi ini jenis tautan yang berbeda (ini bukan tautan yang disebutkan namanya).

Tautan keras hanyalah entri direktori tambahan yang menunjuk ke inode itu. Saat Anda ls -l, nomor setelah izin adalah jumlah tautan yang dinamai. Sebagian besar file biasa akan memiliki satu tautan. Membuat tautan keras baru ke file akan membuat kedua nama file menunjuk ke inode yang sama. catatan:

% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r--  1 danny  staff  0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
-rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3
            ^
            ^ this is the link count

Sekarang, Anda dapat dengan jelas melihat bahwa tidak ada yang namanya tautan keras. Tautan keras sama dengan nama biasa. Dalam contoh di atas, testatau test2, mana file asli dan mana yang merupakan tautan keras? Pada akhirnya, Anda tidak dapat benar-benar tahu (bahkan oleh cap waktu) karena kedua nama menunjuk ke konten yang sama, inode yang sama:

% ls -li test*  
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
14445892 -rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3

The -ibendera untuk lsmenunjukkan nomor inode pada awal baris. Perhatikan caranya testdan test2memiliki nomor inode yang sama, tetapi test3memiliki nomor yang berbeda.

Sekarang, jika Anda diizinkan melakukan ini untuk direktori, dua direktori berbeda di titik berbeda dalam sistem file dapat menunjuk ke hal yang sama. Bahkan, subdir dapat menunjuk kembali ke kakek-neneknya, membuat satu lingkaran.

Mengapa loop ini menjadi perhatian? Karena ketika Anda melintasi, tidak ada cara untuk mendeteksi Anda mengulang (tanpa melacak nomor inode saat Anda melintasi). Bayangkan Anda sedang menulis duperintah, yang perlu diulang melalui subdir untuk mencari tahu tentang penggunaan disk. Bagaimana bisa dutahu kapan itu mengenai lingkaran? Ini rawan kesalahan dan banyak pembukuan yang duharus dilakukan, hanya untuk melakukan tugas sederhana ini.

Symlinks adalah binatang yang sama sekali berbeda, dalam arti mereka adalah jenis "file" khusus yang cenderung diikuti oleh banyak sistem file API. Catatan, symlink dapat menunjuk ke tujuan yang tidak ada, karena mereka menunjuk berdasarkan nama, dan tidak langsung ke inode. Konsep itu tidak masuk akal dengan tautan keras, karena keberadaan "tautan keras" semata-mata berarti file itu ada.

Jadi mengapa bisa duberurusan dengan symlink dengan mudah dan bukan tautan keras? Kami dapat melihat di atas bahwa tautan keras tidak dapat dibedakan dari entri direktori normal. Namun, tautannya spesial, dapat dideteksi, dan dapat diabaikan!  dupemberitahuan bahwa symlink adalah symlink, dan melompati sepenuhnya!

% ls -l 
total 4
drwxr-xr-x  3 danny  staff  102 Oct 13 18:14 test1/
lrwxr-xr-x  1 danny  staff    5 Oct 13 18:13 test2@ -> test1
% du -ah
242M    ./test1/bigfile
242M    ./test1
4.0K    ./test2
242M    .

7
Allowing hard links to directories would break the directed acyclic graph structure of the filesystem. Bisakah Anda jelaskan lebih lanjut tentang masalah dengan siklus menggunakan tautan keras? Mengapa ok dengan symlink
user3539

33
Mereka tampaknya telah mengizinkannya di Mac dengan menambahkan deteksi siklus ke tautan () panggilan sistem, dan menolak untuk memungkinkan Anda membuat tautan keras direktori jika itu akan membuat siklus. Tampaknya menjadi solusi yang masuk akal.
psusi

10
@psusi mkdir -pa / b; nocheckln ca; mv ca / ​​b; - nocheckln ada ln teoritis yang tidak memeriksa direktori args, dan hanya melewati untuk menghubungkan, dan karena tidak ada siklus dibuat, kita semua baik dalam menciptakan 'c'. lalu kita memindahkan 'c' ke 'a / b', dan sebuah siklus dibuat dari a / b / c -> a / - check in tautan () tidak cukup baik
Danny Dulai

3
Siklusnya sangat buruk. Windows memiliki masalah ini dengan "persimpangan" yang merupakan direktori tautan keras. Jika Anda secara tidak sengaja menerapkan izin ke seluruh profil Anda, itu mengungkap serangkaian persimpangan yang menciptakan siklus tak terbatas. Berulang melalui direktori berulang sampai batas panjang jalur menghentikannya.
doug65536

4
@WhiteWinterWolf, menurut tautan ini, mereka secara khusus menambahkan dukungan untuk mesin waktu, tetapi hanya root yang diizinkan melakukannya: superuser.com/questions/360926/…
psusi

14

Dengan pengecualian mount point, setiap direktori memiliki satu dan hanya orang tua: ...

Salah satu cara yang harus dilakukan pwdadalah memeriksa perangkat: inode for '.' dan '..'. Jika keduanya sama, Anda telah mencapai root dari sistem file. Jika tidak, cari nama direktori saat ini di induk, dorong itu di tumpukan, dan mulai membandingkan '../.' dengan '../ ..', lalu '../../.' dengan '../../ ..', dll. Setelah Anda mencapai root, mulailah bermunculan dan mencetak nama-nama dari tumpukan. Algoritma ini bergantung pada fakta bahwa setiap direktori memiliki satu dan hanya satu induk.

Jika tautan keras ke direktori dibolehkan, yang mana dari beberapa orang tua yang harus ..ditunjukkan? Itulah salah satu alasan kuat mengapa hardlink ke direktori tidak diperbolehkan.

Symlinks ke direktori tidak menyebabkan masalah itu. Jika suatu program menginginkannya, itu bisa dilakukan lstat()pada setiap bagian pathname dan mendeteksi kapan symlink ditemukan. The pwdalgoritma akan mengembalikan path absolut berlaku untuk direktori target. Fakta bahwa ada bagian teks di suatu tempat (symlink) yang menunjuk ke direktori target cukup banyak tidak relevan. Keberadaan symlink seperti itu tidak membuat lingkaran dalam grafik.


3
Tidak begitu yakin tentang ini. Jika kita dianggap ..sebagai semacam hardlink virtual ke induk, tidak ada alasan teknis bahwa target tautan hanya dapat memiliki satu tautan lain ke sana. pwdhanya perlu menggunakan algoritma yang berbeda untuk menyelesaikan jalur.
Benubird

13

Anda dapat menggunakan bind mount untuk mensimulasikan direktori penautan yang sulit

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory

7

Saya ingin menambahkan beberapa poin lagi tentang pertanyaan ini. Tautan keras untuk direktori diizinkan di linux, tetapi dengan cara terbatas.

Salah satu cara kita dapat menguji ini adalah ketika kita daftar isi direktori kita menemukan dua direktori khusus "." dan "..". Seperti yang kita tahu "." menunjuk ke direktori yang sama dan ".." menunjuk ke direktori induk.

Jadi mari kita buat pohon direktori di mana "a" adalah direktori induk yang memiliki direktori "b" sebagai anaknya.

 a
 `-- b

Catat inode direktori "a". Dan ketika kita melakukan ls -ladari direktori "a" kita bisa melihatnya "." direktori juga menunjuk ke inode yang sama.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a

Dan di sini kita dapat menemukan bahwa direktori "a" memiliki tiga tautan keras. Ini karena inode 797358 memiliki tiga hardlink atas nama "." di dalam direktori "a" dan beri nama ".." di dalam direktori "b" dan satu dengan nama "a" itslef.

$ ls -ali a/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .

$ ls -ali a/b/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 ..

Jadi di sini kita dapat memahami bahwa tautan keras ada untuk direktori hanya untuk terhubung dengan direktori induk dan anak mereka. Dan direktori tanpa anak hanya akan memiliki 2 hardlink, dan direktori "b" hanya akan memiliki dua hardlink.

Salah satu alasan mengapa tautan keras direktori secara bebas dicegah adalah untuk menghindari loop referensi tanpa batas yang akan membingungkan program yang melintasi sistem file.

Karena filesystem diatur sebagai pohon dan karena pohon tidak dapat memiliki referensi siklik, ini seharusnya dihindari.


1
Contoh yang baik. Itu menghapus keraguan saya. Jadi kasus-kasus ini ditangani dengan cara khusus untuk menghindari loop tak terbatas. Baik?
G Gill

1
Karena kami memiliki cara terbatas untuk memungkinkan tautan keras ke direktori, yaitu ".." dan "." kita tidak akan mencapai loop yang tak terbatas dan karenanya kita tidak akan memerlukan cara khusus untuk menghindari hal-hal itu karena hal itu tidak akan terjadi :)
Kannan Mohan

6

Tak satu pun dari berikut ini adalah alasan sebenarnya untuk melarang tautan keras ke direktori; setiap masalah cukup mudah dipecahkan:

  • siklus dalam struktur pohon menyebabkan traversal yang sulit
  • banyak orang tua, jadi mana yang "asli"?
  • pengumpulan sampah filesystem

The Alasan sebenarnya (sebagaimana diisyaratkan oleh @ Thorbjørn Ravn Andersen) datang ketika Anda menghapus sebuah direktori yang memiliki beberapa orang tua, dari direktori yang ditunjuk oleh ..:

Apa yang ..sekarang harus menunjuk?

Jika direktori dihapus dari induknya tetapi jumlah tautannya masih lebih besar dari 0itu pasti ada sesuatu, di suatu tempat masih menunjuk ke sana. Anda tidak bisa membiarkan ..menunjuk apa-apa; banyak program bergantung .., sehingga sistem harus menelusuri seluruh sistem file sampai menemukan hal pertama yang menunjuk ke direktori yang dihapus, hanya untuk memperbarui ... Entah itu, atau sistem file harus mempertahankan daftar semua direktori yang menunjuk ke direktori yang ditautkan.

Either way, ini akan menjadi overhead kinerja dan komplikasi tambahan untuk meta data sistem file dan / atau kode, sehingga desainer memutuskan untuk tidak mengizinkannya.


3
Itu juga mudah dipecahkan: simpan daftar orang tua dari direktori anak, yang Anda perbarui saat Anda menambah atau menghapus tautan ke anak. Ketika Anda menghapus orang tua kanonik (target anak ..), perbarui ..untuk menunjuk ke salah satu orang tua lain dalam daftar.
jathd

2
Saya setuju. Bukan ilmu roket untuk dipecahkan. Tetapi meskipun demikian overhead kinerja, dan itu akan memakan sedikit ruang ekstra dalam meta data sistem file dan menambah kerumitan. Dan para desainer memilih pendekatan yang sederhana dan cepat - jangan izinkan tautan ke direktori sulit.
Lqueryvg

1
Tautan sym ke dirs "melanggar semantik dan perilaku menetap", namun masih diizinkan. Oleh karena itu beberapa perintah memerlukan opsi untuk mengontrol apakah tautan sym diikuti (misalnya -L di find dan cp). Ketika sebuah program mengikuti '..' ada kebingungan lebih lanjut, maka perbedaan dalam output dari pwd dan / bin / pwd setelah melintasi tautan sym. Tidak ada "Unix jawaban"; keputusan desain saja. Yang ini berputar di sekitar apa yang menjadi ".." seperti yang saya nyatakan dalam jawaban saya. Sayangnya, '..' bahkan tidak disebutkan dalam jawaban bahwa semua orang dengan sangat malu memilih.
Lqueryvg

BTW, saya tidak mengatakan saya mendukung tautan keras ke dir. Tidak semuanya. Saya tidak ingin pekerjaan saya menjadi lebih sulit dari yang sudah ada.
Lqueryvg

Bukan itu yang POSIX katakan, tetapi IMO '..' seharusnya tidak pernah menjadi konsep sistem file, tetapi diselesaikan secara sintaksis di jalurnya, jadi itu a/..selalu berarti .. Inilah cara kerja URL, btw. Ini adalah browser yang menyelesaikan '..' sebelum bahkan hits server. Dan itu bekerja dengan baik.
ybungalobill

3

Pembuatan hardlink pada direktori tidak akan dapat dikembalikan. Misalkan kita memiliki:

/dir1
├──this.txt
├──directory
│  └──subfiles
└──etc

Saya menghubungkannya dengan hardlink /dir2.

Jadi /dir2sekarang juga berisi semua file dan direktori ini

Bagaimana jika saya berubah pikiran? Saya tidak bisa rmdir /dir2(karena tidak kosong)

Dan jika saya secara rekursif menghapus /dir2... itu juga akan dihapus /dir1!

IMHO itu alasan yang cukup memadai untuk menghindari ini!

Sunting :

Komentar menyarankan untuk menghapus direktori dengan melakukannya rm. Tetapi rmpada direktori non-kosong gagal, dan perilaku ini harus tetap, apakah direktori tersebut di-hardlink atau tidak. Jadi Anda tidak bisa rmmembatalkannya. Ini akan membutuhkan argumen baru untuk rm, hanya untuk mengatakan "jika inode direktori memiliki jumlah referensi> 1, maka hanya putuskan tautan direktori".

Yang, pada gilirannya, melanggar prinsip lain yang paling tidak mengejutkan: itu berarti bahwa penghapusan hardlink direktori yang baru saja saya buat tidak sama dengan penghapusan hardlink file normal ...

Saya akan mengulangi kalimat saya: Tanpa pengembangan lebih lanjut, pembuatan hardlink tidak akan dapat dikembalikan (karena tidak ada perintah saat ini yang bisa menangani penghapusan tanpa tidak mengerti perilaku saat ini)

Jika kami mengizinkan pengembangan lebih lanjut untuk menangani kasus ini, jumlah jebakan, dan risiko kehilangan data jika Anda tidak cukup mengetahui bagaimana sistem bekerja, seperti yang disiratkan oleh pengembangan, apakah IMHO alasan yang cukup untuk membatasi hardlinking pada direktori.


Itu seharusnya tidak menjadi masalah. Dengan kasus Anda, saat kami membuat hardlink ke dir2, kami harus membuat hardlink ke semua konten dalam dir1 dan jadi jika kami mengganti nama atau menghapus dir2, hanya tautan tambahan ke inode yang dihapus. Dan itu seharusnya tidak mempengaruhi dir1 dan kontennya karena ada setidaknya satu tautan (dir1) ke inode.
Kannan Mohan

3
Argumen Anda salah. Anda hanya akan memutuskan tautannya, jangan lakukan rm -rf. Dan jika jumlah tautan mencapai 0, maka sistem akan tahu itu dapat menghapus semua konten juga.
LtWorf

Itu semua kurang lebih semua di rmbawahnya toh (batalkan tautan). Lihat: unix.stackexchange.com/questions/151951/… Ini benar-benar bukan masalah, apalagi dengan file yang di-hardlink. Membatalkan tautan hanya menghapus referensi yang disebutkan dan mengurangi jumlah tautan. Fakta bahwa rmdirtidak akan menghapus direktori tidak kosong adalah tidak relevan - tidak akan melakukan itu dir1 juga. Hardlink bukan salinan data, mereka adalah file aktual yang sama, karenanya sebenarnya "menghapus" file dir2 akan menghapus daftar direktori untuk dir1. Anda harus selalu membatalkan tautan.
BryKKan

Anda tidak bisa hanya memutuskan tautannya seperti file normal, karena rmpada direktori jangan memutuskan tautannya jika itu tidak kosong. Lihat Edit.
Pierre-Olivier Vares

1

Ini penjelasan yang bagus. Mengenai "Yang mana dari beberapa orang tua yang harus ... tunjuk?" satu solusi akan untuk suatu proses untuk mempertahankan path wd penuh, baik sebagai inode atau sebagai string. inode akan lebih kuat karena nama dapat diubah. Setidaknya di masa lalu, ada inode in-core untuk setiap file yang terbuka yang bertambah setiap kali file dibuka, dikurangi ketika ditutup. Ketika mencapai nol dan penyimpanan yang ditunjuk akan dibebaskan. Ketika file tidak lagi dibuka oleh siapa pun, itu (Salinan dalam-inti) akan ditinggalkan. Ini akan mempertahankan jalur sebagai valid jika beberapa proses lain memindahkan direktori ke direktori lain sementara subdirektori berada di jalur proses lain. Mirip dengan bagaimana Anda dapat menghapus file yang terbuka tetapi hanya dihapus dari direktori,

Direktori penghubung keras dulu diizinkan secara bebas di Bell Labs UNIX, setidaknya V6 dan V7, Tidak tahu tentang Berkeley atau yang lebih baru. Tidak perlu bendera. Bisakah kamu membuat loop? Ya, jangan lakukan itu. Sangat jelas apa yang Anda lakukan jika Anda membuat lingkaran. Nether jika Anda berlatih mengikat simpul di leher Anda saat Anda sedang menunggu giliran Anda untuk melompat keluar dari pesawat jika Anda memiliki ujung yang lain digantung dengan mudah dari kait di kepala-massal.

Apa yang saya harap akan dilakukan hari ini adalah menghubungkan hard-lhome ke rumah sehingga saya dapat memiliki / home / administ tersedia atau tidak / home ditutup dengan automout over home, automount tersebut memiliki symlink bernama administ to / lhome / kelola. Ini memungkinkan saya untuk memiliki akun administratif yang berfungsi terlepas dari keadaan sistem file rumah utama saya. Ini adalah percobaan untuk linux, tapi saya pikir belajar pada satu waktu untuk SunOS berbasis UCB bahwa automount dilakukan pada level string ascii. Sulit untuk melihat bagaimana mereka dapat dilakukan sebaliknya sebagai lapisan di atas FS sembarang.

Saya membaca di tempat lain itu. dan .. bukan file lagi di direktori. Saya yakin bahwa ada alasan bagus untuk semua ini, dan banyak dari apa yang kami nikmati (Seperti dapat me-mount NTFS) adalah mungkin karena hal-hal seperti itu, tetapi beberapa keanggunan UNIX ada dalam implementasi. Inilah manfaat seperti sifat umum dan kelenturan yang diberikan keanggunan ini yang memungkinkannya begitu kuat dan bertahan selama empat dekade. Ketika kita kehilangan implementasi elegan itu pada akhirnya akan menjadi seperti Windows (saya harap saya salah!). Seseorang kemudian akan membuat OS baru yang didasarkan pada prinsip-prinsip elegan. Sesuatu untuk dipikirkan. Mungkin saya salah, saya tidak (jelas) akrab dengan implementasi saat ini. ini adalah luar biasa meskipun bagaimana pemahaman 30 tahun berlaku untuk Linux ... sebagian besar waktu!


Saya pikir, meskipun saya mungkin salah, itu .dan ..bukan hardlinks dalam sistem file, untuk sistem file modern. Namun driver sistem file membuat mereka salah. Ini adalah sistem file yang menghentikan direktori yang menghubungkan dengan keras. Untuk sistem file lama dimungkinkan (tetapi berbahaya). Untuk melakukan apa yang Anda coba, lihat mount --bind, lihat juga mount --make…dan mungkin wadah.
ctrl-alt-delor

0

Dari apa yang saya kumpulkan, alasan utamanya adalah berguna untuk dapat mengubah nama direktori tanpa mengacaukan program yang sedang berjalan yang menggunakan direktori kerja mereka untuk merujuk file lain. Misalkan Anda menggunakan Wine untuk menjalankan ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe, dan Anda ingin memindahkan seluruh awalan ~/.wine. Jika karena alasan yang aneh, Firefox mengakses drive_c/windowsdengan merujuk ../../windows, mengubah nama ~/.newwineprefixmemecah implementasi ..yang melacak direktori induk sebagai string teks dan bukannya inode.

Menyimpan inode dari direktori induk tunggal harus lebih sederhana daripada mencoba melacak setiap path sebagai string teks dan serangkaian inode.

Alasan lain adalah bahwa aplikasi yang keliru mungkin dapat membuat loop. Berperilaku aplikasi harus dapat memeriksa apakah inode direktori yang sedang dipindahkan adalah sama dengan inode dari direktori bersarang yang dipindahkan, sama seperti Anda tidak dapat memindahkan direktori ke dalam dirinya sendiri, tetapi ini mungkin tidak ditegakkan di tingkat sistem file.

Namun alasan lain mungkin bahwa jika Anda dapat mengarahkan direktori, Anda ingin mencegah menghubungkan direktori yang tidak dapat Anda modifikasi. findmemiliki pertimbangan keamanan karena digunakan untuk menghapus file yang dibuat oleh pengguna lain dari direktori sementara, yang dapat menyebabkan masalah jika pengguna mengganti direktori nyata untuk symlink saat findmenjalankan perintah lain. Mampu menghubungkan direktori-direktori penting dengan hardlink akan memaksa administrator untuk menambahkan tes tambahan findagar tidak memengaruhi mereka. (Oke, Anda sudah tidak dapat melakukan ini untuk file, jadi alasan ini tidak valid.)

Namun alasan lain adalah bahwa menyimpan inode direktori induk dapat memberikan redundansi tambahan jika terjadi kerusakan atau kerusakan sistem file. Jika Anda ingin ..membuat daftar semua direktori induk yang memiliki tautan keras ke direktori ini, maka induk yang berbeda dan sewenang-wenang dapat dengan mudah ditemukan jika direktori saat ini dihapus, tidak hanya Anda melanggar gagasan bahwa tautan keras sama, Anda harus mengubah cara sistem file menyimpan dan menggunakan inode. Memiliki program memperlakukan jalur sebagai serangkaian (unik untuk setiap hardlink) dari direktori inode akan menghindari ini, tetapi Anda tidak akan mendapatkan redundansi jika terjadi kerusakan sistem file.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.