Dopo un'ulteriore riflessione (e il tuo commento), mi rendo conto che esiste una solida base comportamentale per la scelta.
Se io:
- apri un file esistente nel tuo editor
- inizia a modificarlo
- realizzare che voglio un backup e spostare (non copiare) l'originale
- salva le mie modifiche
dovrebbe alterare il backup (l'inode originale con un nuovo nome)? O scrivi il file alterato sul nome originale, lasciando il backup da solo?
Penso che quest'ultimo, il che implica che non dovrebbe mantenere aperto il file originale in quanto non sarà in grado di utilizzare comunque quel descrittore di file / FILE* in modo sicuro. Potresti decidere di volere un comportamento diverso, però.
Bene, in che stato ex (o vi) è necessario tenere traccia di ogni file?
Fuori dalla mia testa, vim ha bisogno di:
- nome file
-
descrittore di file o FILE*
potrebbe essere -1 o NULL se non è aperto? (i file nella lista buffer sono aperti anche se non sono visualizzati? Non lo so, ma potrebbe essere ragionevole chiudere i file e conservare una voce per essi)
-
swapfile - la fd sopra dovrebbe riferirsi a questo? dobbiamo anche tenere traccia del nome del file di scambio?
- stato di modifica
-
leggi le ultime statistiche del file originale (in modo che tu possa sapere se è cambiato prima di sovrascrivere)
o forse solo un flag "file sottostante modificato", se si desidera utilizzare le notifiche di modifica file
-
che sia di sola lettura o di lettura-scrittura (potresti solo provare per scrivere e ottenere un errore, ma ... ick)
- convenzione di fine riga, codifica
Si noti che posso avere più buffer che guardano diverse posizioni nello stesso file, e possibilmente con impostazioni diverse (evidenziazione della sintassi, numeri di linea ecc.), quindi quelle non possono essere proprietà del file stesso.
Ora, a meno che non si possa dedurre da tutto ciò da un singolo descrittore di file, penso che sia necessario qualche struct che lo memorizzi (e possibilmente di più).