17Aug
Quando utilizzi Linux e OS X, il sistema operativo non ti impedirà di eliminare un file attualmente in uso su Windows, ma ti verrà espressamente vietato farlo. Cosa dà?Perché è possibile modificare ed eliminare file in uso su sistemi derivati da Unix ma non su Windows?
Today's Question &La sessione di risposta ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di Q & A basato su community.
The Question
SuperUser reader the.midget vuole sapere perché Linux e Windows trattano i file in uso in modo diverso:
Una delle cose che mi ha lasciato perplesso sin da quando ho iniziato a usare Linux è il fatto che ti permette di cambiare il nome diun file o addirittura cancellarlo mentre viene letto. Un esempio è come ho tentato involontariamente di cancellare un video mentre era in riproduzione. Ci sono riuscito, e sono rimasto sorpreso quando ho saputo che puoi modificare praticamente qualsiasi cosa in un file senza preoccuparti se al momento è in uso o meno.
Quindi cosa sta succedendo dietro le quinte e impedendogli di eliminare volutamente le cose in Windows come può fare in Linux?
I contributori di Answer
SuperUser fanno luce sulla situazione di the.midget. Scritture stupite:
Ogni volta che apri o esegui un file in Windows, Windows blocca il file in posizione( questa è una semplificazione, ma in genere vera). Un file bloccato da un processo non può essere eliminato finché tale processo non lo rilascia. Questo è il motivo per cui ogni volta che Windows deve aggiornarsi è necessario un riavvio perché abbia effetto.
D'altra parte, i sistemi operativi di tipo Unix come Linux e Mac OS X non bloccano il file ma piuttosto i settori del disco sottostanti. Questo può sembrare una banale differenziazione ma significa che il record del file nel sommario del filesystem può essere cancellato senza disturbare nessun programma che abbia già aperto il file. Quindi puoi cancellare un file mentre è ancora in esecuzione o in altro modo in uso e continuerà a esistere su disco purché alcuni processi abbiano un handle aperto per esso anche se la sua voce nella tabella file è scomparsa.
David Schwartz amplia l'idea e sottolinea come dovrebbero essere le cose idealmente e come sono nella pratica:
Windows imposta automaticamente il blocco automatico e obbligatorio dei file. UNIXes predefiniti al blocco manuale e cooperativo dei file. In entrambi i casi, i valori predefiniti possono essere annullati, ma in entrambi i casi di solito non lo sono.
Un sacco di vecchio codice di Windows utilizza l'API C / C ++( funzioni come fopen) piuttosto che l'API nativa( funzioni come CreateFile).L'API C / C ++ non consente in alcun modo di specificare il funzionamento del blocco obbligatorio, in modo da ottenere i valori predefiniti. La "modalità condivisa" predefinita tende a proibire operazioni "in conflitto".Se si apre un file per la scrittura, si presume che le scritture siano in conflitto, anche se non si scrive mai effettivamente nel file. Idem per i nomi.
E, ecco dove va peggio. Oltre all'apertura per lettura o scrittura, l'API C / C ++ non fornisce alcun modo per specificare cosa si intende fare con il file. Quindi l'API deve presumere che stai per eseguire qualsiasi operazione legale. Poiché il blocco è obbligatorio, un open che consente un'operazione in conflitto verrà rifiutato, anche se il codice non ha mai avuto l'intenzione di eseguire l'operazione in conflitto ma stava semplicemente aprendo il file per un altro scopo.
Quindi, se il codice utilizza l'API C / C ++ o utilizza l'API nativa senza pensare specificamente a questi problemi, finirà per impedire il set massimo di operazioni possibili per ogni file che aprono e non riescono ad aprire un file a meno che tutte le operazioni possibiliPotrebbero esibirsi su di esso una volta aperto non è in conflitto.
A mio parere, il metodo Windows funzionerebbe molto meglio del metodo UNIX se ogni programma scegliesse le sue modalità di condivisione e le modalità aperte gestendo i casi di insuccesso in modo oculato e saggiamente. Il metodo UNIX, tuttavia, funziona meglio se il codice non si preoccupa di pensare a questi problemi. Sfortunatamente, l'API di base C / C ++ non si adatta bene all'API di file di Windows in un modo che gestisce bene le modalità di condivisione e le aperture in conflitto. Quindi il risultato netto è un po 'confuso.
Ecco qua: due diversi approcci alla gestione dei file producono due risultati diversi.
Hai qualcosa da aggiungere alla spiegazione? Sound off nei commenti. Vuoi leggere più risposte dagli altri utenti di Stack Exchange esperti di tecnologia? Controlla la discussione completa qui.