Mengapa saya tidak dapat mengubah nama file yang sedang dibaca di Windows seperti yang dapat saya lakukan di Linux / Mac?


23

Salah satu hal yang membingungkan saya sejak saya mulai menggunakan Linux adalah kenyataan bahwa ia memungkinkan Anda untuk mengubah nama file atau bahkan menghapusnya saat sedang dibaca. Contohnya adalah bagaimana saya secara tidak sengaja mencoba menghapus video saat sedang diputar. Saya berhasil, dan terkejut ketika saya mengetahui bahwa Anda dapat mengubah apa saja dalam file tanpa peduli apakah itu sedang digunakan saat ini atau tidak.


2
Mengganti nama file yang terkunci tidak menjadi masalah pada Windows. Menghapus biasanya, ada beberapa program yang membuka file dengan opsi FILE_SHARE_DELETE dihidupkan.
Hans Passant

Anda sebenarnya tidak menghapusnya, Anda hanya memutuskan tautannya dari direktori tempat file itu ada. File tersebut masih ada, mungkin saja tidak memiliki nama di sistem file. (Meskipun masih memiliki nama di Internet /proc filesystem melalui program yang membukanya.) File hanya dapat dihapus jika tidak ada referensi yang tersisa, dan ini terjadi secara otomatis.
David Schwartz

Jawaban:


35

Setiap kali Anda membuka atau menjalankan file di Windows, Windows mengunci file di tempatnya (ini adalah penyederhanaan, tetapi biasanya benar.) File yang dikunci oleh suatu proses tidak dapat dihapus sampai proses itu melepaskannya. Inilah sebabnya mengapa setiap kali Windows harus memperbarui sendiri, Anda perlu mem-boot ulang agar bisa berlaku.

Di sisi lain, sistem operasi mirip Unix seperti Linux dan Mac OS X tidak mengunci file melainkan sektor disk yang mendasarinya. Ini mungkin tampak diferensiasi sepele tetapi itu berarti bahwa catatan file dalam daftar isi filesystem dapat dihapus tanpa mengganggu program apa pun yang sudah membuka file tersebut. Jadi Anda dapat menghapus file saat masih dieksekusi atau sedang digunakan dan itu akan terus ada di disk selama beberapa proses memiliki pegangan terbuka untuk itu meskipun entri dalam tabel file hilang.


2
Terima kasih atas jawaban ini. Ini menjelaskan perbedaannya kepada saya lebih banyak. Ini juga membantu menjelaskan mengapa memuat file / video besar tidak memakan banyak RAM. Jika tidak, memainkan satu video besar dapat merusak seluruh sistem Anda.
Jerry Saravia

4
Jika Anda menghapus file yang digunakan, dan Anda ingin mendapatkannya kembali di Linux, Anda bisa menemukan entri file di / proc, seperti yang dijelaskan dalam pertanyaan ini .
Ken Bloom

2
Ini agak generalisasi - tidak semua pembaruan Windows hari ini (pada Windows 7) memerlukan reboot, dan saya sudah melakukan banyak hal di Linux.
Alan B

10

Windows default ke otomatis, penguncian file wajib. UNIX default untuk penguncian file secara manual dan kooperatif. Dalam kedua kasus, standarnya bisa diganti, tetapi dalam kedua kasus biasanya tidak.

Banyak kode Windows lama menggunakan C / C ++ API (fungsi suka fopen ) daripada API asli (fungsi suka CreateFile ). C / C ++ API tidak memberi Anda cara untuk menentukan bagaimana penguncian wajib akan bekerja, sehingga Anda mendapatkan default. "Mode berbagi" default cenderung melarang operasi "bentrok". Jika Anda membuka file untuk menulis, menulis dianggap bertentangan, bahkan jika Anda tidak pernah benar-benar menulis ke file. Ditto untuk mengganti nama.

Dan, di sinilah semakin buruk. Selain membuka untuk membaca atau menulis, API C / C ++ tidak memberikan cara untuk menentukan apa yang ingin Anda lakukan dengan file tersebut. Jadi, API harus menganggap Anda akan melakukan operasi hukum apa pun. Karena penguncian adalah wajib, sebuah open bahwa memungkinkan operasi yang bertentangan akan ditolak, bahkan jika kode tidak pernah dimaksudkan untuk melakukan operasi yang bertentangan tetapi hanya membuka file untuk tujuan lain.

Jadi jika kode menggunakan C / C ++ API, atau menggunakan API asli tanpa secara khusus memikirkan masalah ini, mereka akan berakhir mencegah set maksimum operasi yang mungkin untuk setiap file yang mereka buka dan tidak dapat membuka file kecuali setiap operasi yang mungkin mereka bisa tampil di atasnya setelah dibuka tidak berbelit-belit.

Menurut pendapat saya, metode Windows akan bekerja jauh lebih baik daripada metode UNIX jika setiap program memilih mode berbagi dan mode terbuka dengan bijak dan bijaksana menangani kasus kegagalan. Metode UNIX, bagaimanapun, bekerja lebih baik jika kode tidak repot memikirkan masalah ini. Sayangnya, API C / C ++ dasar tidak memetakan dengan baik ke file API Windows dengan cara yang menangani mode berbagi dan konflik terbuka dengan baik. Jadi hasil akhirnya agak berantakan.


0

Ini adalah pertanyaan yang sangat menarik dan membuat saya berpikir tentang jawaban yang masuk akal. Saya harap orang lain dapat menyediakan cadangan di sini.

Saya menggunakan Windows dan Linux dan memperhatikan ini juga. Saya juga pengguna vim. Vim akan membaca file teks menjadi 'buffer', atau RAM, dan kemudian tidak menyentuh file yang sebenarnya sampai Anda simpan. Linux mungkin melakukan tindakan semacam ini secara umum dengan semua file.

Ambil video Anda misalnya, itu membaca video, semuanya jika mungkin, ke dalam RAM, dan kemudian Anda memiliki salinan video yang mudah diakses, dicari, dapat dilompati. Jika file terlalu besar maka Anda mungkin mengalami masalah karena Linux mungkin tidak membaca seluruh video, mungkin hanya sebagian besar. Saat pemutar Anda sampai di akhir video yang disangga itu akan mencoba membaca file lagi. Jika Anda telah menghapus video maka itu menyebalkan untuk Anda.

Windows adalah OS yang jauh lebih 'aman' dalam beberapa kasus karena itu tidak akan membiarkan Anda melakukan itu. Mungkin buffer file dengan cara yang sama seperti Linux tetapi juga menambahkan penguncian file untuk mencegah Anda, atau program lain, dari mengubah file yang sedang Anda kerjakan atau lihat. Ini membantu menjaga file tetap utuh dan membuat Anda atau program lain tidak menimpa perubahan satu sama lain.


Kamu tidak bisa benar-benar menghapus saya t. Cukup gerakkan dan ganti nama.
Daniel Beck

2
Anda bisa 'rm' itu. Itu cukup dekat untuk menghapusnya.
Chris Moore
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.