Qual è il concetto di creare un file con zero byte in Linux?

Se faccio quanto segue:

touch /tmp/test

e quindi eseguire

ls -la /tmp/

Ho potuto vedere il testfile con 0 byte nella directory.

Ma come fa il sistema operativo a gestire un concetto di 0 byte . Se lo metto in parole povere:

0 byte non è affatto memoria, quindi non viene creato nulla.

Creazione di un file, deve o dovrebbe richiedere almeno una certa memoria, giusto?

Un file è (approssimativamente) tre cose separate:

• Un "inode", una struttura di metadati che tiene traccia di chi possiede il file, le autorizzazioni e un elenco di blocchi sul disco che effettivamente contengono i dati.
• Una o più voci della directory (i nomi dei file) che puntano a quell'inode
• Gli stessi blocchi di dati stessi

Quando si crea un file vuoto, si creano solo l'inode e una voce di directory che punta a tale inode. Lo stesso vale per i file sparsi ( dd if=/dev/null of=sparse_file bs=10M seek=1).

Quando si creano collegamenti fisici a un file esistente, è sufficiente creare voci di directory aggiuntive che puntano allo stesso inode.

Ho semplificato le cose qui, ma hai capito.

touchcreerà un inode , e ls -io statmostrerà informazioni circa l'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: -

Si noti che testutilizza 0 blocchi. Per memorizzare i dati visualizzati, l'inode utilizza alcuni byte. Quei byte sono memorizzati nella tabella degli inode. Guarda la pagina ext2 per un esempio di una struttura di inode .

ls(o bene, la stat(2)chiamata di sistema) ti dice la dimensione del contenuto del file. La quantità di spazio di cui il filesystem ha bisogno per la contabilità non fa parte di questo, e come dettaglio di implementazione, non è qualcosa che i programmi in generale dovrebbero preoccuparsi o addirittura conoscere. Rendere visibili i dettagli dell'implementazione renderebbe meno utile l'astrazione del filesystem.

Il file stesso non occupa alcuno spazio, ma lo fa il file system, memorizzando il nome file, la posizione, i diritti di accesso ad esso e simili.

Risposta semplice: perché è definita in questo modo.

Risposta più lunga: è definita in questo modo perché alcune operazioni sono concettualmente più semplici:

• Se un file contiene 20 lettere "A" e si rimuovono tutte le "A", il file diventerà più corto di 20 byte. La stessa operazione su un file che consisteva solo in "AAAAAAAAAAAAAAAAAAAA" avrebbe dovuto occuparsi del caso speciale di un file in via di estinzione.
• Più praticamente, l'eliminazione dell'ultima riga di un file di testo dovrebbe essere specificata in maiuscolo.
• Gli editor di testo che effettuano regolarmente un backup avrebbero bisogno di un codice di caso speciale per gestire la situazione in cui l'utente potrebbe eliminare l'ultima riga, andare a pranzo, quindi tornare e aggiungere un'altra riga. Ulteriori complicazioni sorgono se nel frattempo altri utenti hanno creato un file con quel nome.

Puoi fare più cose: * I file di log degli errori tendono a essere creati vuoti, da riempire se e solo se si verifica un errore. * Per scoprire quanti errori si sono verificati, contare il numero di righe nei file di registro. Se il file di registro è vuoto, il numero di errori è zero, il che ha perfettamente senso. * A volte vedi file in cui tutto il testo rilevante è nel nome del file, ad es this-is-the-logging-directory. Ciò impedisce agli amministratori di livello eccessivo di eliminare le directory vuote dopo l'installazione e impedisce anche bug in cui un programma o un utente crea accidentalmente un file in cui il programma vorrebbe vedere una directory in un secondo momento. Il gitprogramma (e altri) tendono a ignorare le directory vuote e se un progetto / amministratore / utente vuole avere un record che la directory esiste anche se non ha ancora un contenuto utile, potresti vedere un file vuoto chiamatoemptyoppure empty.directory.

Nessuna operazione diventa più complicata:

• Concatenare i file: questo è solo un no-op con un file vuoto.
• Ricerca di una stringa in un file: questo è coperto dal caso standard di "se il file è più corto del termine di ricerca, non può contenere il termine di ricerca".
• Lettura dal file: i programmi devono affrontare la fine del file prima di ottenere ciò che si aspettavano, quindi il caso di un file di lunghezza zero non implica un pensiero extra per il programmatore: colpirà solo la fine del -file dall'inizio.

Nel caso dei file, l'aspetto "c'è un file registrato da qualche parte" (inode e / o nome del file) si aggiunge alle considerazioni precedenti, ma i file system non lo farebbero se i file vuoti fossero inutili.

In generale, tutti i motivi sopra indicati, ad eccezione di quelli relativi ai nomi dei file, si applicano alle sequenze. Soprattutto per le stringhe, che sono sequenze di caratteri: le stringhe a lunghezza zero sono all'ordine del giorno all'interno dei programmi. Le stringhe sono generalmente vietate a livello utente se non hanno senso: un nome file è una stringa e la maggior parte dei file system non consente una stringa vuota come nome file; internamente, durante la creazione di nomi di file da frammenti, il programma potrebbe avere una stringa vuota come uno dei frammenti.

Usando l'analogia più semplice:

Confrontiamo un file con, diciamo, un bicchiere d'acqua.

'touch / tmp / test' è molto simile alla creazione di un bicchiere vuoto, senza acqua. Il bicchiere è vuoto, quindi la sua dimensione è zero. Ma il bicchiere esiste.

Nel linguaggio dei file system, il vetro è i metadati, mentre il contenuto del vetro è i dati. I metadati contengono tutti i tipi di cose come menzionato nei post precedenti.

I file di dimensioni zero possono essere utili. Un esempio è usarli come briciole di pane, in cui la sua mera esistenza può essere usata per indicare una sorta di stato (cioè, se il file esiste: allora fai qualcosa; in caso contrario: ignora).

Pensaci in questo modo: supponi che un programma stia monitorando le query SQL inviate al tuo server. Il programma vuole indicare che sta registrando le richieste in un file di testo semplice, ma nessuna richiesta è stata ancora registrata. Come dovrebbe essere? Direi che dovrebbe essere un file di dimensioni zero su /var/log/acme-sql-server/queries.log. In questo modo, è possibile capire quando è iniziata la registrazione (l'ora di creazione del file), quando è stato aggiornato l'ultima volta (ovvero quando è stato creato), quante query sono state registrate (numero di nuove righe nel file = 0) e chi sta eseguendo la registrazione (Acme SQL Server). Per casi come questo, è utile avere il concetto di un file vuoto che esiste comunque in una posizione particolare.