De ce nu pot modifica fișierele de pe Windows cum ar fi eu pe Linux și OS X?

Când utilizați Linux și OS X, sistemul de operare nu vă va împiedica să ștergeți un fișier utilizat în prezent, dar pe Windows veți fi în mod explicit interzis să faceți acest lucru. Ce dă? De ce puteți edita și șterge fișierele în uz în sistemele derivate de la Unix, dar nu în Windows?

Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor web Q & A.

Intrebarea

Cititorul SuperUser the.midget vrea să știe de ce Linux și Windows tratează în mod diferit fișierele în uz:

Unul dintre lucrurile care mi-a nedumerit încă de când am început să folosesc Linux este faptul că vă permite să modificați numele unui fișier sau chiar să îl ștergeți în timp ce acesta este citit. Un exemplu este cum am încercat accidental să șterg un videoclip în timp ce acesta se joacă. Am reușit și am fost surprins când am învățat că poți schimba aproape orice în fișier fără a te îngriji dacă este folosit în acest moment sau nu.

Deci, ce se întâmplă în spatele scenei și împiedicându-l să șterge în mod intenționat lucrurile în Windows, așa cum se poate în Linux?

Răspunsul

Contribuitorii de la SuperUser au aruncat o lumină asupra situației. Uimit scrie:

Ori de câte ori deschideți sau executați un fișier în Windows, Windows blochează fișierul în loc (aceasta este o simplificare, dar de obicei este adevărată.) Un fișier care este blocat de un proces nu poate fi șters până când acest proces îl eliberează. De aceea, ori de câte ori Windows trebuie să se actualizeze, este nevoie de o repornire pentru ca aceasta să aibă efect.

Pe de altă parte, sistemele de operare asemănătoare Unix precum Linux și Mac OS X nu blochează fișierul, ci mai degrabă sectoarele de discuri subiacente. Acest lucru poate părea o diferențiere trivială, dar înseamnă că înregistrarea fișierului în tabela de conținut a sistemului de fișiere poate fi ștearsă fără a deranja niciun program care are deja fișierul deschis. Deci, puteți să ștergeți un fișier în timp ce se execută încă sau altfel în uz și va continua să existe pe disc, atâta timp cât un proces are un mâner deschis pentru el chiar dacă intrarea sa în tabela de fișiere a dispărut.

David Schwartz se extinde asupra ideii și evidențiază modul în care ar trebui să fie lucrurile în mod ideal și cum sunt ele în practică:

Windows implicit implică blocarea automată a fișierelor. UNIX implicit la blocarea manuală a fișierelor de tip cooperativă. În ambele cazuri, valorile implicite pot fi suprasolicitate, dar în ambele cazuri acestea nu sunt de obicei.

O mulțime de cod vechi Windows utilizează C / C ++ API (funcții ca fopen), mai degrabă decât API nativ (funcții precum CreateFile). API-ul C / C ++ vă oferă nicio modalitate de a specifica modul în care va funcționa blocarea obligatorie, astfel încât să obțineți valorile implicite. Modul de partajare implicit tinde să interzică operațiunile "conflictuale". Dacă deschideți un fișier pentru scriere, se presupune că scrierea este în conflict, chiar dacă nu scrieți niciodată fișierul. Ditto pentru redenumiri.

Și, aici se înrăutățește. În afară de deschiderea pentru citire sau scriere, C / C ++ API nu oferă nicio modalitate de a specifica ce intenționați să faceți cu fișierul. Prin urmare, API trebuie să presupună că veți efectua orice operațiune legală. Deoarece blocarea este obligatorie, o deschidere care permite o operație în conflict va fi refuzată, chiar dacă codul nu intenționa niciodată să efectueze operația conflictuală, ci doar deschide fișierul pentru alt scop.

Deci, dacă codul folosește API-ul C / C ++ sau folosește API-ul nativ fără să se gândească în mod special la aceste probleme, acestea vor elimina setul maxim de posibile operații pentru fiecare fișier pe care îl deschid și dacă nu pot deschide un fișier, ar putea efectua pe ea odată deschis este neconflict.

În opinia mea, metoda Windows ar funcționa mult mai bine decât metoda UNIX dacă fiecare program și-a ales modurile de partajare și deschide modurile cu înțelepciune și corectă tratare a cazurilor de eșec. Metoda UNIX, cu toate acestea, funcționează mai bine dacă codul nu se deranjează să se gândească la aceste probleme. Din păcate, API-ul C / C ++ de bază nu se potrivește bine în API-ul fișierului Windows într-un mod care să se ocupe de modurile de partajare și conflictele se deschid bine. Deci rezultatul net este un pic dezordonat.

Acolo îl aveți: două abordări diferite ale procesării fișierelor produc două rezultate diferite.

Aveți ceva de adăugat la explicație? Sunați în comentariile. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.