Mengapa menyimpan tautan mandiri dan induk (. Dan ..) dalam entri direktori?

11

Pertimbangkan sistem file yang ditargetkan pada beberapa perangkat tertanam yang tidak lebih dari menyimpan file dalam struktur direktori hierarkis. Sistem file ini tidak memiliki banyak operasi yang dapat Anda gunakan dalam sistem seperti unix dan Windows (misalnya, izin aksesnya sangat berbeda dan tidak terikat dengan metadata yang disimpan dalam direktori). Sistem file ini tidak mengizinkan segala jenis tautan keras atau tautan lunak, sehingga setiap file memiliki nama unik dalam struktur pohon yang ketat.

Apakah ada manfaat untuk menyimpan tautan ke direktori itu sendiri dan ke induknya dalam struktur data di-disk yang mewakili direktori?

Sebagian besar sistem file unix memiliki .dan ..entri pada disk. Saya bertanya-tanya mengapa mereka tidak menangani mereka di lapisan VFS (driver sistem file generik). Apakah ini artefak sejarah? Apakah ada alasan yang bagus, dan jika demikian, yang tepatnya, jadi saya dapat menentukan apakah itu relevan dengan sistem embedded saya?

operating-systems filesystems

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

Saya selalu berpikir mereka ada di sana hanya secara virtual sehingga program dapat dengan mudah mengakses direktori saat ini dan orang tua. Pertanyaan yang menarik, tetapi apakah itu termasuk di sini?

— Raphael

@ Raphael Saya bisa mengerti jika Anda menganggap pertanyaan saya terlalu luas (→ "bukan pertanyaan nyata"), atau mungkin "tidak konstruktif", karena agak terbuka. Tapi saya tidak setuju bahwa ini di luar topik: ini tentang desain sistem file, bagaimana itu tidak diterapkan dalam ilmu komputer? Jika menurut Anda di luar topik, jelaskan alasan Anda tentang meta.

— Gilles 'SO- stop being evil'

@ Raphael Saya telah mengedit pertanyaan saya, semoga jelas bahwa sudut pandang saya adalah desainer OS yang tertanam. Terima kasih atas komentar anda

— Gilles 'SO- stop being evil'

2

Memiliki tautan ke direktori induk masuk akal bagi saya. Jika Anda tidak memilikinya, Anda harus selalu bekerja dengan seluruh daftar direktori. Jadi, misalnya, /home/svick/Documents/harus diwakili sebagai { /, /home/, /home/svick/, /home/svick/Documents }. Jika Anda tidak melakukan itu, Anda tidak akan dapat menemukan direktori induk sama sekali (atau itu akan sangat mahal). Ini tidak hanya tidak efisien, tetapi juga berbahaya. Jika Anda memiliki dua daftar yang tumpang tindih, mereka dapat dengan mudah menyinkronkan jika Anda memindahkan beberapa direktori.

Di sisi lain, jika Anda memiliki referensi ke direktori induk, ini lebih efisien dan lebih aman.

Saya tidak melihat alasan untuk benar-benar memiliki tautan ke direktori saat ini. Jika Anda memiliki struktur yang mewakili beberapa direktori dan Anda ingin mengakses direktori itu, menggunakan .selalu sama sekali tidak perlu. Karena itu, saya berharap bahwa .tautannya tidak benar-benar ada dalam struktur sistem berkas dan hanya virtual.

— svick
sumber

2

Komentar yang sama: mengapa melakukannya di setiap sistem file daripada di lapisan VFS? Sebagian besar sistem file Linux memang memiliki .dan ..entri.

— Gilles 'SO- stop being evil'

Seperti yang saya katakan, saya pikir ini lebih efisien. Anda dapat bekerja hanya dengan direktori saat ini, dan mengakses orang tuanya hanya saat Anda membutuhkan. Jika Anda tidak memiliki tautan induk, Anda harus selalu menyimpan semua direktori di seluruh jalur dari root di memori. Dan Anda akan membutuhkannya untuk setiap entri yang Anda gunakan.

— svick

1

@svick: Gilles tidak membandingkan memiliki tautan induk dengan tidak memiliki tautan induk. Dia membandingkan memiliki mereka dalam sistem file yang sebenarnya dengan mereka disimulasikan oleh lapisan antara kode (vfs) antara sistem file aktual dan ruang pengguna.

— rgrig

2

Anda mendapatkan lebih sedikit case khusus. Dalam banyak situasi, VFS dapat menangani ".." karena menangani nama direktori lain.

— rgrig
sumber

3

Jika direktori adalah virtual, program (usermode I presume) masih dapat menanganinya sebagai direktori lain. Anda tidak benar-benar membutuhkan tautan untuk ditampilkan di tingkat penyimpanan.

— Aryabhata

1

Ya, tapi mengapa tidak mengatasinya di lapisan VFS? Mengapa ada penyimpanan terkait?

— Gilles 'SO- stop being evil'

Mengapa orang menerapkan daftar tertaut dengan sentinel alih-alih menangani kasus daftar kosong di fungsi tambah / hapus?

— rgrig

@ rgrig: Ini terjadi hanya ketika antarmuka ke implementasi daftar tertaut dianggap ditulis dalam bahasa yang sangat buruk dalam menangani struktur data induktif (C, Java, dll ...). Di sini masalah ini tidak relevan karena lapisan VFS tidak dapat diakses langsung dari sudut pandang pengguna.

— Stéphane Gimenez

@ StéphaneGimenez: Masalah ini adalah relevan, karena VFS adalah ditulis dalam C.

— rgrig

2

Satu-satunya alasan yang dapat saya bayangkan adalah skenario berikut:

Implementasi asli dari sistem file ada dengan format direktori yang sama tetapi gagasan jalur file dan subdirektori tidak dipertimbangkan pada waktu itu (Lihat sistem file PDP-7 Unix ).
Kemudian orang berpikir bahwa resolusi jalur dan subdirektori akan berguna!
Untuk menjaga sejumlah kompatibilitas dengan implementasi yang lebih lama, diputuskan bahwa .dan ..akan disimpan pada disk sama seperti direktori lainnya.

Jadi mungkin kita ditinggalkan dengan artefak yang tidak berguna itu, hanya demi kompatibilitas dengan perangkat lunak yang sudah berusia 40 tahun? Skenario yang dapat dipercaya?

Catatan: Juga tidak sepenuhnya bodoh untuk menambahkan entri ini ke daftar direktori, karena Anda perlu menyimpan nomor inode dari direktori induk asli Anda di suatu tempat (ingat bahwa hardlink pada direktori diperbolehkan saat ini), dan referensi ke Anda nomor inode sendiri mungkin pemeriksaan kewarasan yang baik.

— Stéphane Gimenez
sumber

1

Saya tidak melihat alasan untuk mengimplementasikan .dan ..di kedua tingkat daripada yang lain. Namun, jika Anda menargetkan sistem tertanam lapisan apa pun yang dapat Anda hemat mungkin merupakan dolar yang diperoleh, jadi mungkin masuk akal untuk mencoba dan mengimplementasikan semuanya serendah mungkin.

Adapun kebutuhan umum .dan .., bagaimana Anda mengekspresikan jalur relatif tanpa mereka? Setidaknya ..sangat diperlukan untuk jalur yang meninggalkan subtree saat ini. Jika Anda tidak memerlukan jalur seperti itu (mungkin pohon merupakan cara primitif untuk menyandikan hak akses?), Anda tidak perlu ...

— Raphael
sumber