Kemana file terbuka menangani pergi ketika mereka mati?


15

Apa yang terjadi pada file yang dihapus ketika mereka memiliki pegangan file terbuka untuk mereka?

Saya telah bertanya-tanya ini sejak saya tahu saya bisa menghapus file video saat sedang diputar di MPlayer dan masih akan bermain sampai akhir. Dari mana data itu diambil? Apakah masih berasal dari hard drive? Apakah itu disalin ke RAM setelah saya menghapus file?

Jika masih ada di hard drive, apa yang terjadi jika saya mengisi sistem file saat program sedang berjalan membaca dari apa yang pada dasarnya ruang yang tidak terisi? Jika buffer dalam RAM, apa yang terjadi jika saya menyiram buffer?

Apa yang terjadi jika file berada di share NFS – apakah disimpan di server? (Bukankah itu risiko keamanan - DoS oleh banyak menangani file jarak jauh yang terbuka?)

Melakukan sesuatu lsof -n |grep '(deleted)'terkadang menghasilkan hasil yang menarik; jika saya memutakhirkan paket yang menukar file perpustakaan bersama, maka menjalankan program yang telah menggunakan perpustakaan itu masih akan dapat menggunakannya seolah-olah tidak ada yang berubah.

Pertanyaan bonus: Apakah ada cara untuk mendapatkan kembali data dari kematian dalam situasi ini?

Jawaban:


13

Inode masih bertahan pada disk, meskipun tidak ada lagi tautan keras ke inode. Mereka akan dihapus ketika deskriptor file ditutup. Sampai saat itu, file dapat dimodifikasi seperti biasa, kecuali operasi yang memerlukan nama file / tautan keras.

debugfs dan alat serupa dapat digunakan untuk memulihkan isi inode.


10
Ini benar, namun jika file masih terbuka, Anda bisa mendapatkannya kembali dengan pergi ke / proc / <PID> / fd di mana PID adalah pid dari sebuah program yang filenya masih terbuka. Direktori ini berisi semua deskriptor file terbuka program, dan Anda dapat mengaksesnya seperti file normal, sehingga Anda dapat membuat tautan keras untuk 'mengembalikan' file.
Patrick

Perhatikan bahwa itu /procadalah Linux-spesifik (sebagaimana adanya debugfs).
Ignacio Vazquez-Abrams

1
Solaris memiliki / proc juga dan tekniknya berfungsi dengan baik. Jangan tahu tentang BSD.
Patrick

2
Saya hanya perlu menambahkan bahwa ini luar biasa.
n0pe

1
@ Patrick: Anda tidak dapat membuat tautan keras untuk 'mengembalikan' file dari /proc. Hard-link hanya berfungsi pada sistem file yang sama, bukan di seluruh sistem file dan karena /procmerupakan sistem file yang tidak dapat ditulis terpisah, Anda tidak dapat membuat tautan keras di dalamnya. Anda dapat menyalin file itu /proc.
camh

5

Kernel tidak menghitung referensi pada referensi ke inode. Lihat jawaban saya untuk Apa yang terjadi ketika saya menutup () deskriptor file? .

Menghapus file yang terbuka kemungkinan tidak lebih efektif dari mekanisme DOS daripada hanya membuka file. File ulimityang terbuka memberikan perlindungan terhadap upaya DOS ini. Ini berlaku untuk semua file yang terbuka, dihapus atau tidak.


5

Suatu file hanya terhapus pada sistem file begitu setiap referensi untuk itu telah hilang. Kedua nama dan pegangan terbuka dihitung sebagai referensi. Selama file terbuka di suatu program, itu tidak dihapus, meskipun sebagian besar sistem tidak memungkinkan Anda untuk membuat ulang nama untuk itu.

Data masih di drive, tetapi file ditandai memiliki jumlah tautan 0. Jika sistem macet, fsck pada reboot berikutnya tahu bahwa itu harus menghapus data. Ini tidak mengarah pada penolakan layanan seperti halnya file yang tidak dihapus.

Anda tidak dapat membuat ulang tautan ke file pada sistem Linux stok sejauh yang saya tahu (tidak melewati driver sistem file dengan debugfsatau metode serupa), tetapi Anda dapat memulihkan konten dengan mudah: di cat /proc/12345/fd/42mana 12345 adalah ID proses yang memiliki file terbuka dan 42 adalah nomor deskriptor file.

Lebih dari NFS, ketika Anda menghapus file yang masih terbuka di beberapa klien, server NFS mengganti nama file di server tetapi tidak menghapusnya sampai semua klien telah merilis file. Dalam pengalaman saya, nama baru itu .nfs…, meskipun saya tidak tahu apakah nama itu sama di semua implementasi NFS.

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.