Apa konsep membuat file dengan nol byte di Linux?

Jika saya melakukan hal berikut:

touch /tmp/test

dan kemudian lakukan

ls -la /tmp/

Saya bisa melihat testfile dengan 0 Bytes di direktori.

Tetapi bagaimana Sistem Operasi menangani konsep 0 Bytes . Jika saya memasukkannya ke dalam istilah awam:

0 Bytes tidak ada memori sama sekali, maka tidak ada yang dibuat.

Pembuatan file, harus atau setidaknya harus memerlukan memori tertentu, bukan?

File adalah (kira-kira) tiga hal terpisah:

• "Inode", struktur metadata yang melacak siapa yang memiliki file, izin, dan daftar blok pada disk yang benar-benar berisi data.
• Satu atau lebih entri direktori (nama file) yang mengarah ke inode itu
• Blok data aktual itu sendiri

Saat Anda membuat file kosong, Anda hanya membuat inode dan entri direktori yang menunjuk ke inode itu. Sama untuk file jarang ( dd if=/dev/null of=sparse_file bs=10M seek=1).

Ketika Anda membuat hardlink ke file yang ada, Anda hanya membuat entri direktori tambahan yang mengarah ke inode yang sama.

Saya telah menyederhanakan hal-hal di sini, tetapi Anda mendapatkan ide.

touchakan membuat inode , dan ls -iatau statakan menampilkan info tentang inode:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

Perhatikan bahwa testmenggunakan 0 blok. Untuk menyimpan data yang ditampilkan, inode menggunakan beberapa byte. Byte tersebut disimpan dalam tabel inode. Lihatlah halaman ext2 untuk contoh struktur inode .

ls(atau juga, stat(2)panggilan sistem) memberi tahu Anda ukuran isi file. Berapa banyak ruang yang dibutuhkan sistem file untuk pembukuan bukan bagian dari itu, dan sebagai detail implementasi, itu bukan sesuatu yang harus diperhatikan atau bahkan diketahui oleh program. Membuat detail implementasi terlihat akan membuat abstraksi filesystem kurang berguna.

File itu sendiri, tidak menempati ruang apa pun, tetapi sistem file, menyimpan nama file, lokasi, hak akses untuk itu dan sejenisnya.

Jawaban sederhana: Karena didefinisikan seperti itu.

Jawaban yang lebih panjang: Ini didefinisikan seperti itu karena beberapa operasi secara konsep lebih sederhana:

• Jika file berisi 20 huruf "A", dan Anda menghapus semua "A", maka file akan menjadi lebih pendek 20 byte. Operasi yang sama pada file yang hanya terdiri dari "AAAAAAAAAAAAAAAAAAAAA" harus berurusan dengan kasus khusus dari file yang hilang.
• Secara lebih praktis, menghapus baris terakhir dari file teks perlu dibuat khusus.
• Editor teks yang secara teratur membuat cadangan akan memerlukan kode kasus khusus untuk menangani situasi di mana pengguna mungkin menghapus baris terakhir, pergi makan siang, lalu kembali dan menambahkan baris lain. Komplikasi lebih lanjut muncul jika beberapa pengguna lain membuat file dengan nama itu untuk sementara waktu.

Anda dapat melakukan lebih banyak hal: * File log kesalahan cenderung dibuat kosong, harus diisi jika dan hanya jika terjadi kesalahan. * Untuk mengetahui berapa banyak kesalahan yang terjadi, Anda menghitung jumlah baris dalam file log. Jika file log kosong, jumlah kesalahan adalah nol, yang masuk akal. * Terkadang Anda melihat file di mana semua teks yang relevan dalam nama file, misalnya this-is-the-logging-directory. Ini mencegah administrator yang terlalu bersemangat menghapus direktori kosong setelah instalasi, dan itu juga mencegah bug di mana suatu program atau pengguna secara tidak sengaja membuat file di mana program ingin melihat direktori nanti. The gitProgram (dan lain-lain) cenderung mengabaikan direktori kosong, dan jika proyek / administrator / user ingin memiliki catatan bahwa direktori ada meskipun tidak memiliki konten yang bermanfaat (belum), Anda mungkin melihat file kosong bernamaemptyatau empty.directory.

Tidak ada operasi yang menjadi lebih rumit:

• File gabungan: ini hanyalah larangan dengan file kosong.
• Mencari string dalam file: ini dicakup oleh kasus standar "jika file lebih pendek dari istilah pencarian, itu tidak dapat berisi istilah pencarian".
• Membaca dari file: program harus berurusan dengan memukul ujung file sebelum mereka mendapatkan apa yang mereka harapkan, jadi sekali lagi kasus file dengan panjang nol tidak melibatkan pemikiran ekstra untuk programmer: ia hanya akan mencapai akhir -file dari awal.

Dalam hal file, aspek "ada file yang direkam di suatu tempat" (inode dan / atau nama file) muncul di atas pertimbangan di atas, tetapi sistem file tidak akan melakukan itu jika file kosong tidak berguna.

Secara umum, semua alasan di atas kecuali yang terkait dengan nama file berlaku untuk urutan. Terutama pada string, yang merupakan urutan karakter: String nol-panjang adalah hal biasa dalam program. String biasanya tidak diizinkan di tingkat pengguna jika tidak masuk akal: nama file adalah string, dan sebagian besar sistem file tidak mengizinkan string kosong sebagai nama file; secara internal, saat membuat nama file dari fragmen, program mungkin memiliki string kosong sebagai salah satu fragmen.

Menggunakan analogi yang paling sederhana:

Mari kita bandingkan file dengan, katakanlah, segelas air.

'touch / tmp / test' sangat mirip dengan membuat gelas kosong, tanpa air di dalamnya. Gelas itu kosong, jadi ukurannya nol. Tapi gelas itu memang ada.

Dalam bahasa sistem file, kaca adalah meta-data, sedangkan isi kaca adalah data. Meta-data berisi segala macam hal seperti yang disebutkan dalam posting sebelumnya.

File berukuran nol dapat bermanfaat. Salah satu contoh adalah menggunakannya sebagai remah roti, di mana keberadaannya dapat digunakan untuk menunjukkan semacam keadaan (yaitu, jika file ada: lalu lakukan sesuatu; jika tidak: abaikan).

Pikirkan seperti ini: katakan bahwa suatu program sedang melacak permintaan SQL yang dikirim ke server Anda. Program ini ingin menunjukkan bahwa ia sedang mencatat permintaan ke file teks biasa, tetapi belum ada permintaan yang telah dicatat. Seperti apa seharusnya itu? Saya berpendapat bahwa itu harus berupa file berukuran nol /var/log/acme-sql-server/queries.log. Dengan begitu, Anda bisa mengetahui kapan logging dimulai (waktu pembuatan file), kapan terakhir diperbarui (yaitu ketika itu dibuat), berapa banyak query yang direkam (jumlah baris baru dalam file = 0), dan siapa yang melakukan logging (Acme SQL Server). Untuk kasus seperti ini, sebaiknya memiliki konsep file kosong yang tetap ada di lokasi tertentu.