17Aug
Când utilizați Linux și OS X, sistemul de operare nu vă va împiedica să ștergeți un fișier utilizat în prezent pe Windows, veți fi în mod expres 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?
Întrebarea de astăzi &Sesiunea de răspuns vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor web Q & A.
Întrebarea
SuperUser cititorul the.midget vrea să știe de ce Linux și Windows tratează fișierele în uz în mod diferit:
Unul dintre lucrurile care mi-a nedumerit încă de când am început să folosesc Linux este faptul că vă permite să schimbați numeleun fișier sau chiar să îl ștergeți în timp ce acesta este citit. Un exemplu este modul în care am încercat accidental să șterg un videoclip în timp ce acesta se joacă.Am reușit și am fost surprins când am aflat că poți schimba ceva din dosar fără să te îngrijești dacă este folosit în acest moment sau nu.
Deci, ce se întâmplă în spatele scenei și care îl împiedică să șterge în mod nemijlocit lucrurile în Windows așa cum se poate în Linux?
Contribuitorii răspunsului
SuperUser au aruncat o lumină asupra situației. Amazed scrie:
Ori de câte ori deschideți sau executați un fișier în Windows, Windows blochează fișierul în loc( 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, de fiecare dată când 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 disc subiacente. Aceasta 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 șterge un fișier în timp ce se execută sau se utilizează în continuare și va continua să existe pe disc, atâta timp cât un proces are un mâner deschis pentru el, chiar dacă intrarea î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 în practică:
Windows implicit implică blocarea automată a fișierelor. UNIX-urile implicite la blocarea manuală a fișierelor cooperative.În ambele cazuri, valorile implicite pot fi suprasolicitate, dar în ambele cazuri acestea nu sunt de obicei.
O mulțime de vechi coduri 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 conflictuală 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ă a se gândi în mod special la aceste probleme, acestea vor preveni setul maxim de operații posibile pentru fiecare fișier pe care îl deschid și nu poate deschide un fișier,pe care le-ar putea face 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ă rezolvare 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 cu API-ul de fișiere Windows într-un mod care se ocupă de modurile de partajare și de conflictele deschise. Deci rezultatul net este un pic dezordonat.
Acolo îl aveți: două abordări diferite de manipulare a fișierelor produc două rezultate diferite.
Trebuie să adăugați ceva 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.