Perché non riesco a modificare i file in uso su Windows come posso fare su Linux e OS X?
Quando utilizzi Linux e OS X, il sistema operativo non ti impedirà di eliminare un file attualmente in uso su Windows a cui ti sarà espressamente vietato farlo. Cosa dà? Perché è possibile modificare ed eliminare file in uso su sistemi derivati da Unix ma non su Windows?
La sessione di domande e risposte di oggi ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte basato sulla comunità.
La domanda
Lettore SuperUser the.midget vuole sapere perché Linux e Windows trattano i file in uso in modo diverso:
Una delle cose che mi ha lasciato perplesso da quando ho iniziato a usare Linux è il fatto che ti permette di cambiare il nome di un file o addirittura cancellarlo mentre viene letto. Un esempio è come ho cercato accidentalmente di cancellare un video mentre era in riproduzione. Ci sono riuscito, e sono rimasto sorpreso quando ho saputo che puoi modificare quasi tutto in un file senza preoccuparti se al momento viene utilizzato o no.
Quindi, cosa sta succedendo dietro le quinte e impedendogli di eliminare volutamente le cose in Windows come può fare con Linux?
La risposta
I collaboratori di SuperUser fanno luce sulla situazione di the.midget. Scritto stupito:
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 dei file è scomparsa.
David Schwartz espande l'idea e sottolinea come le cose dovrebbero essere idealmente e come sono nella pratica:
Il valore predefinito di Windows è 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 qui è 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 la serie massima di operazioni possibili per ogni file che aprono e non riescono ad aprire un file a meno che tutte le operazioni possibili non siano potrebbe eseguire 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 di 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 danno 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.
