Ja jūs izmantojat Linux un OS X, operētājsistēma neapstāsies, ka jūs joprojām neizdzēsīsit šobrīd vēl izmantojamo failu Windows, jums to tieši nepieļaus. Kas dod? Kāpēc jūs varat rediģēt un dzēst lietojamos failus no Unix sistēmām, bet ne Windows?
Šodienas jautājumu un atbilžu sesija mums priecājas par SuperUser - Stack Exchange dalību, kas ir kopienas vadīta Q & A tīmekļa vietņu grupa.
SuperUser lasītājs the.Midget vēlas uzzināt, kāpēc Linux un Windows apstrādā lietojamos failus citādi:
Viena no lietām, kas ir mani mulsina, kopš es sāku izmantot Linux, ir fakts, ka tas ļauj mainīt faila nosaukumu vai pat dzēst to, kamēr tas tiek lasīts. Piemērs ir tas, kā es nejauši mēģināju dzēst videoklipu, kamēr tas tika atskaņots. Man ir izdevies un esmu pārsteigts, jo es uzzināju, ka jūs varat mainīt tikai visu, kas atrodas failā, neuztraucoties, vai tas šobrīd tiek izmantots vai ne.
Tātad, kas notiek aiz ainas un neļauj tam nekļūdīgi dzēst lietas Windows, piemēram, viņš var Linux?
SuperUser atbalstītāji izskaidro situāciju, kas saistīta ar mēmizmēģinājumu. Amazed raksta:
Ikreiz, kad atverat vai izpildāt failu sistēmā Windows, sistēma Windows bloķē failu (tas ir vienkāršošana, bet parasti tā ir taisnība). Failu, ko bloķē kāds process, nevar izdzēst, kamēr šis process to neizlaiž. Tāpēc ikreiz, kad operētājsistēmai Windows ir jāatjaunina pati programma, tā ir jāpārstart, lai tā stātos spēkā.
No otras puses, Unix līdzīgās operētājsistēmas, piemēram, Linux un Mac OS X, failu neaizsargā, bet gan pamatā esošie diska sektori. Tas var šķist nenozīmīgas diferenciācijas, bet tas nozīmē, ka faila ierakstu faila sistēmas satura rādītājā var izdzēst, netraucējot nevienu programmu, kurai jau ir atvērts fails. Tātad jūs varat izdzēst failu, kamēr tas joprojām tiek izpildīts vai citādi tiek izmantots, un tas turpinās pastāvēt diskā, kamēr kādam procesam ir atvērts rokturis, lai gan tā ieraksts failu tabulā ir pagājis.
David Schwartz izvērš ideju un uzsver, kā viss būtu ideāli un kā tas ir praktiski:
Windows noklusējumiem ir automātiska, obligāta failu bloķēšana. UNIXs pēc noklusējuma ir manuāla, kooperatīva failu bloķēšana. Abos gadījumos noklusējumus var pārtvert, bet abos gadījumos tie parasti nav.
Vecā Windows koda daudz izmanto C / C ++ API (funkcijas, piemēram, fopen), nevis vietējo API (funkcijas, piemēram, CreateFile). C / C ++ API neļauj norādīt, kā darbojas obligātā bloķēšana, tādējādi jūs saņemsiet noklusējumus. Noklusējuma "koplietošanas režīms" parasti aizliedz "konfliktējošas" darbības. Ja atverat failu rakstīšanai, tiek pieņemts, ka rakstiski tiek konflikti, pat ja jūs nekad faktiski rakstāt failā. Tas pats par pārdēvēšanu.
Un šeit tā kļūst sliktāka. C / C ++ API, izņemot atvēršanu lasīšanai vai rakstīšanai, nav veids, kā norādīt, ko jūs plānojat darīt ar failu. Tātad API ir jāpieņem, ka jūs gatavojaties veikt jebkādu juridisku darbību. Tā kā bloķēšana ir obligāta, tiek atvērta atļauja, kas ļauj konfliktējošu darbību atspēkot, pat ja kods nekad nav paredzēts veikt konfliktējošo operāciju, bet tikai atver failu citiem mērķiem.
Tātad, ja kods izmanto C / C ++ API vai izmanto vietējo API, nekoncentrējoties domājot par šiem jautājumiem, tie izbeigs, novēršot maksimālo iespējamo darbību skaitu katram atvērtam failam un nespējot to atvērt, izņemot gadījumus, kad katra iespējamā darbība varēja to paveikt, kad atvērts ir nekontrolēts.
Manuprāt, Windows metode darbosies daudz labāk nekā UNIX metode, ja katra programma izvēlēsies savas koplietošanas režīmus un atvērto režīmu gudri un rūpīgi apstrādātu neveiksmju gadījumus. UNIX metode tomēr darbojas labāk, ja kods neuztraucas domāt par šiem jautājumiem. Diemžēl C / C ++ API pamatvirziens neder mapē uz Windows failu API tādā veidā, kas apstrādā koplietošanas režīmus, un labi atveras konfliktu risinājumi. Tātad neto rezultāts ir nedaudz netīrs.
Tur jums tas ir: divas atšķirīgas pieejas failu apstrādei dod divus dažādus rezultātus.
Vai kaut ko pievienot paskaidrojumam? Skatieties komentāros. Vēlaties lasīt citas atbildes no citiem tehnoloģiju savvy Stack Exchange lietotājiem? Šeit skatiet pilnu diskusiju pavedienu.
