Bagaimana perilaku file terbuka di sistem linux?

17

Saya baru saja mengganti nama file log menjadi "foo.log.old", dan mengasumsikan bahwa aplikasi akan mulai menulis file log baru di "foo.log". Saya terkejut menemukan bahwa ia melacak logfile ke nama barunya, dan terus menambahkan baris ke "foo.log.old".

Di Windows, saya tidak terbiasa dengan perilaku semacam ini - saya tidak tahu apakah itu mungkin untuk diterapkan. Bagaimana tepatnya perilaku ini diterapkan di linux? Di mana saya bisa belajar lebih banyak tentang itu?

files open-files rename

— ripper234
sumber

Saya tidak menempatkan ini sebagai jawaban karena saya tidak benar-benar tahu tetapi saya pikir ini ada hubungannya dengan inode yang tidak diubah ketika Anda memindahkan file.

— mathepic

20

Program terhubung ke file melalui nomor yang dikelola oleh filesystem (disebut inode pada filesystem unix tradisional), yang namanya hanya referensi (dan mungkin bukan referensi unik pada saat itu).

Jadi beberapa hal yang harus diperhatikan:

Memindahkan file menggunakan mvtidak mengubah nomor bawahan itu kecuali Anda memindahkannya di sistem file (yang setara dengan menggunakan cpkemudian rmpada aslinya).
Karena lebih dari satu nama dapat terhubung ke satu file (yaitu kita memiliki tautan keras), data dalam file "dihapus" tidak hilang sampai semua referensi ke file bawahan hilang.
Mungkin yang paling penting: ketika sebuah program openmenyimpan file, ia membuat referensi untuknya yang (untuk keperluan kapan data akan dihapus) setara dengan memiliki nama file yang terhubung dengannya.

Ini menimbulkan beberapa perilaku seperti:

Suatu program dapat openfile untuk dibaca, tetapi tidak benar-benar membacanya sampai setelah pengguna seperti rmmengeditnya di baris perintah, dan program masih akan memiliki akses ke data .
Yang Anda temui: mvfile tidak memutuskan hubungan antara file dan program apa pun yang dibuka (kecuali jika Anda bergerak melintasi batas-batas sistem file, dalam hal ini program masih memiliki versi asli untuk dikerjakan).
Jika suatu program memiliki openfile untuk ditulis, dan rmnama file terakhir pengguna pada baris perintah, program dapat tetap dengan benar memasukkan hal-hal ke dalam file, tetapi begitu ditutup, tidak akan ada lagi referensi untuk data itu dan itu akan hilang.
Dua program yang berkomunikasi melalui satu atau lebih file dapat memperoleh keamanan parsial yang kasar dengan menghapus file setelah selesai open. (Ini bukan pikiran keamanan yang sebenarnya , itu hanya mengubah lubang menganga menjadi kondisi ras.)

— dmckee
sumber

1

Saya setuju dengan @dmckee, saya hanya ingin mencatat: sebuah program dapat openfile untuk membaca dan menulis (seperti apa yang terjadi dengan file log dalam pertanyaan).

— jsbillings

@ jsbillings: Ya, tetapi ada risiko. Jika semua nama sistem file hilang, Anda dapat menulis GB ke file terbuka yang akan menguap seperti embun pagi segera setelah Anda menutupnya.

— dmckee

1

Juga, inode disalin ke dalam kernel dan itulah yang dioperasikan, bukan salinan disk. Jadi file tersebut bisa mv'd atau cp ', tetapi file yang terbuka sudah bekerja dengan struktur data kernal, bukan versi disk. Jadi jika Anda menyalin file lain ke dalam file yang terbuka untuk ditulis, prosesnya masih akan menulis ke posisi relatif yang sama seperti pada file lama. Ini adalah alasan mengapa program, seperti Apache httpd, memiliki penangan sinyal yang menutup dan membuka kembali file log.

— Arcege

0

Untuk benar-benar melihat bagaimana perilaku ini diterapkan, Anda dapat melihat beberapa buku pemrograman Unix. Mathepic benar karena terkait dengan inode. Pathname yang sebenarnya hanya digunakan untuk membuka file, setelah itu dilakukan program referensi oleh deskriptor file yang dibuka. Deskriptor file pada gilirannya referensi inode, yang dalam hal ini tidak peduli jika nama file yang mendasarinya telah berubah.

Sejauh menerapkan ini di Windows, itu pertanyaan untuk situs lain.

Untuk membaca lebih lanjut tentang ini tanpa memukul buku-buku hanya mencari-cari sistem file dan inode linux. Mungkin tidak ada jawaban yang jelas, tetapi Anda akan dapat memahami alasannya.

— Tuan Shickadance
sumber

4

"Cari di sekitar - Anda mungkin tidak akan menemukan jawaban yang baik tetapi akan memahaminya" bukan jawaban yang baik.

— mattdm