Връзка с поддръжката

Отговаряме по имейл, обикновено до два дни.

Google reCAPTCHA проверява това изпращане срещу злоупотреби; данни се изпращат към Google. Скриптът се зарежда само когато този формуляр бъде отворен.

← Всички публикации

Какво всъщност засяга изтриването на брояч

Изтриването на брояч тук изчиства 33 таблици. Вчера изчистваше 25.

Осемте, които пропускаше, бяха създадени предишния ден, между 11:10 сутринта и 15:10 следобед.

33 таблици съхраняват нещо за брояча 8 от тях не се изчистваха — всички създадени предишния ден в тези осем имаше общо 4 840 реда добавени днес на азбучното им място, а не в края 25 осиротели реда, открити в други таблици и премахнати

Как работи изтриването

Собственикът може да изтрие своя брояч. За това са нужни POST заявка, токенът на собственика и номерът на брояча, въведен на ръка, защото няма отмяна. Нищо не се заделя настрана: скрито копие би било обратното на поисканото, а връзките за експорт стоят над бутона за всеки, който иска копие.

После списък от таблици се изчиства в една транзакция, основната таблица последна, а в архива отива надгробен запис, за да не може номерът никога да бъде даден на някой друг. Ако някоя част се провали, всичко се връща назад. По-добре нищо изтрито, отколкото наполовина изтрито.

Над този списък във файла стои следният коментар:

„Всяка таблица, която знае нещо за този брояч. Като списък, а не пръснато из кода: каквото липсва тук, остава като осиротял ред и никой не забелязва.“

Коментарът описваше пропуска един ден, преди той да се отвори

Вчера се появиха шест нови таблици за нова функционалност — време на страницата, дълбочина на превъртане, страници на излизане — заедно с още две. Между 11:10 и 15:10.

Списъкът за изтриване беше редактиран същия ден, за да се добави друга нова таблица. Осемте дойдоха след това и списъкът повече не беше пипан. Така за един следобед изтриването на брояч оставяше след себе си 4 840 реда данни за поведение, разпръснати в осем таблици. Пропускът беше открит на следващия ден и затворен; той показа, че на списъка е нужно нещо различно от паметта, за да остане пълен.

Това не е история за небрежност. Някой е написал списъка, разбирал е точно защо той е списък, записал е какво става, когато изостане, и го е обновил същия ден за една таблица. И той пак изостана, защото да държиш две неща в синхрон, като помниш да го правиш, е нещо, което хората правят надеждно точно до следобеда, в който не го правят.

Поправката и другата поправка

Осемте имена вече са в списъка. Вмъкнати са на азбучните си места, а не добавени в края, защото в подреден списък пропускът се вижда, а в списък, към който само се добавя в края, не се вижда.

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

При първото си изпълнение той откри и нещо друго: 25 реда в още осем таблици, чийто номер на брояч го няма нито в работещата таблица, нито в архива. Не изтрити броячи — те оставят надгробен запис. Номера, които не принадлежат на нищо, повечето от тях явни тестови номера от времето, преди да съществува проверката в архива. Те бяха записани във файл извън основната уеб директория и после премахнати.

Какво следва от това по принцип

Всеки списък, който трябва да се държи в синхрон с нещо друго, рано или късно ще излезе от синхрон и пропускът ще е невидим, защото списък, в който липсва запис, изглежда точно като пълен списък.

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

Коментарът над списъка беше прав за всичко освен за една дума. Пишеше, че никой не забелязва. Някой забеляза, един ден по-късно, защото потърси със скрипт, а не с паметта си.

Реклама