Когато използвате Linux и OS X, операционната система няма да ви попречи да изтриете файл, който се използва в момента, в Windows ще бъдете изрично забранени. Какво дава? Защо можете да редактирате и изтривате файлове за използване на Unix-derived системи, но не и Windows?
Днешната сесия за въпроси и отговори ни идва с любезното съдействие на SuperUser - подразделение на Stack Exchange - обединяване на уеб сайтове с въпроси и отговори.
Reader на SuperUser the.midget иска да знае защо Linux и Windows третират по-различно файловете за използване:
Едно от нещата, които ме озадачаваха още от началото на използването на Линукс, е фактът, че ви позволява да променяте името на даден файл или дори да го изтриете, докато го четете. Пример за това е как случайно се опитах да изтрия видеоклип, докато той се възпроизвеждаше. Успях и бях изненадан, когато научих, че можете да променяте почти всичко във файл, без да се грижите, ако се използва в момента или не.
И така, какво се случва зад кулисите и не му позволява да изтрива ненужно неща в Windows, както може и в Linux?
Привържениците на SuperUser хвърлят светлина върху ситуацията. Удивен пише:
Винаги, когато отваряте или изпълнявате файл в Windows, Windows заключва файла на място (това е опростяване, но обикновено е вярно). Файлът, който е заключен чрез процес, не може да бъде изтрит, докато този процес не бъде освободен. Ето защо, когато Windows трябва да се актуализира, трябва да рестартирате, за да влезе в сила.
От друга страна, подобни на Unix операционни системи, като Linux и Mac OS X, не блокират файла, а по-скоро секторите на дисковете. Това може да изглежда тривиално диференциране, но това означава, че записът на файла в таблицата със съдържание на файловата система може да бъде изтрит, без да се нарушава никоя програма, която вече има отворен файл. Така че можете да изтриете файл, докато той все още се изпълнява или по друг начин се използва, и той ще продължи да съществува на диск, докато някой процес има отворена дръжка за него, въпреки че неговият запис в таблицата с файлове е изчезнал.
Дейвид Шварц разширява идеята и подчертава как идеите трябва да бъдат идеални и как те са на практика:
Windows подразбира автоматично, задължително заключване на файлове. UNIX е по подразбиране за ръчно, съвместно заключване на файлове. И в двата случая неизпълнението може да бъде отменено, но в двата случая те обикновено не са.
Много от старите кодове на Windows използват C / C ++ API (функции като fopen), а не природните API (функции като CreateFile). C / C ++ API не ви дава възможност да определите колко задължително заключване ще работи, за да получите по подразбиране. По подразбиране режимът на споделяне има за цел да забрани "противоречиви" операции. Ако отворите файл за писане, пише се, че се сблъсква с конфликт, дори и да не пишете в него. Също така за преименувания.
И ето къде се влошава. Освен отварянето за четене или писане, C / C ++ API не дава възможност да се уточни какво искате да направите с файла. Така че API трябва да приеме, че ще извършите някаква правна операция. Тъй като заключването е задължително, отвореното, което позволява конфликтна операция, ще бъде отказано, дори ако кодът никога не е възнамерявал да извърши конфликтната операция, а просто е отворил файла за друга цел.
Така че ако кодът използва API C / C ++ или използва приложния API, без да се замисля специално за тези проблеми, те ще прекратят максималния набор от възможни операции за всеки отворен файл и не могат да отворят файл, освен ако не е възможно всяка операция може да изпълнява върху него, след като е отворен, няма конфликти.
По мое мнение, методът на Windows ще работи много по-добре от метода UNIX, ако всяка програма избере режимите си на споделяне и отвори режимите, като разумно и внимателно се справя с дефектите. Методът UNIX обаче работи по-добре, ако кодът не се притеснява да мисли за тези проблеми. За съжаление, основният C / C ++ API не се насочва добре към приложния програмен интерфейс (API) на файловете на Windows по начин, който се занимава с режими на споделяне и конфликтите се отварят добре. Така че нетният резултат е малко объркан.
Имате го: два различни подхода за обработка на файловете дават два различни резултата.
Имате ли нещо, което да добавите към обяснението? Звучи в коментарите. Искате ли да прочетете повече отговори от други потребители на Stack Exchange? Вижте цялата тема на дискусията тук.
