Защо не мога да променям файловете, които се използват в Windows като мога на Linux и OS X?

Когато използвате Linux и OS X, операционната система няма да ви попречи да изтриете файл, който в момента се използва в Windows, ще бъдете изрично забранени за това. Какво дава? Защо можете да редактирате и изтривате файлове, които се използват в Unix-базирани системи, но не и Windows?

Днешната сесия за въпроси и отговори идва при нас с любезното съдействие на SuperUser - подразделение на Stack Exchange, групирано от общността уеб сайтове за въпроси и отговори.

Въпроса

Четецът на SuperUser the.midget иска да знае защо Linux и Windows третират по различен начин файловете в употреба:

Едно от нещата, които ме озадачиха откакто започнах да използвам Linux, е фактът, че ви позволява да промените името на файла или дори да го изтриете, докато се чете. Пример за това е как случайно се опитах да изтрия видеоклип, докато той се възпроизвеждаше. Успях и бях изненадан, когато научих, че можеш да промениш почти всичко във файл, без да се грижиш дали се използва в момента или не.

Така че това, което се случва зад кулисите и го предпазва от безсмислено изтриване на неща в Windows, както може в Linux?

Отговорът

Собствениците на SuperUser хвърлиха светлина върху ситуацията за. Amazed пише:

Всеки път, когато отваряте или изпълнявате файл в Windows, Windows заключва файла на място (това е опростяване, но обикновено е вярно.) Файл, който е заключен от процес, не може да бъде изтрит, докато този процес не го пусне. Ето защо, когато Windows се обновява, трябва да се рестартира, за да влезе в сила.

От друга страна, Unix-подобни операционни системи като Linux и Mac OS X не заключват файла, а по-скоро основните дискови сектори. Това може да изглежда тривиална диференциация, но това означава, че записът на файла в съдържанието на файловата система може да бъде изтрит, без да се нарушава всяка програма, която вече има отворен файл. Така че можете да изтриете файл, докато той все още се изпълнява или по друг начин се използва, и той ще продължи да съществува на диска, докато някой процес има отворена дръжка за него, въпреки че вписването му в таблицата с файлове е изчезнало.

Дейвид Шварц разширява идеята и подчертава как трябва да бъдат идеалните неща и как те са на практика:

Windows по подразбиране е автоматично, задължително заключване на файлове. UNIX по подразбиране е ръчно, кооперативно заключване на файлове. И в двата случая настройките по подразбиране могат да бъдат отменени, но и в двата случая те обикновено не са.

Много стари кодове на Windows използват C / C ++ API (функции като fopen), а не родния API (функции като CreateFile). C / C ++ API не ви дава възможност да посочите как ще работи задължителното заключване, така че ще получите настройките по подразбиране. По подразбиране “режимът на споделяне” има тенденция да забранява “конфликтни” операции. Ако отворите файл за писане, пише се, че се конфликтира, дори ако никога всъщност не пишете във файла. Същото важи и за преименуванията.

И ето къде се влошава. Освен за отваряне за четене или запис, C / C ++ API не дава възможност да се уточни какво възнамерявате да правите с файла. Така че API трябва да приеме, че ще изпълнявате всяка правна операция. Тъй като заключването е задължително, отворено, което позволява конфликтна операция, ще бъде отказано, дори ако кодът никога не е имал за цел да изпълни конфликтната операция, а е само отваряне на файла за друга цел..

Така че, ако кодът използва C / C ++ API, или използва родния API, без да мисли специално за тези проблеми, те ще преустановят максималния набор от възможни операции за всеки отворен файл и не могат да отворят файл, освен ако всяка възможна операция те може да изпълнява на него веднъж отворен е несъвместим.

Според мен методът на Windows ще работи много по-добре от метода на UNIX, ако всяка програма избира своите режими на споделяне и отворени режими разумно и разумно се справя с случаи на неуспех. Методът UNIX обаче работи по-добре, ако кодът не си прави труда да мисли за тези проблеми. За съжаление, основният C / C ++ API не се свързва добре с файловия API на Windows по начин, който управлява режимите на споделяне и противоречиво се отваря добре. Така че нетният резултат е малко разхвърлян.

Тук имате: два различни подхода за работа с файлове дават два различни резултата.

Имате ли какво да добавите към обяснението? Звукът е изключен в коментарите. Искате ли да прочетете повече отговори от други технологични потребители на Stack Exchange? Вижте пълната тема за дискусия тук.