[-] [2642] Некорректная работа с бэкапами настроек

[Alex-D]

Проблема не относится к конкретному билду - скорее, к любому.
На ПК существуют ситуации, когда например внезапно отказал жесткий диск или драйвер диска, или сама система ввода-вывода ОС если её что-то повесило. В таких случаях при попытках записать в файл на диске новые данные, вместо данных могут записаться нули, 0x00 (вернее, файл резервируется для записи, обнуляется - но фактической записи не происходит). И это на самом деле не так уж и редко - просто это не всегда можно заметить. Я так терял уже множество данных в браузере, например.

Касаемо плеера. Плеер каждый раз создаёт бэкапы всех предыдущих ini-параметров профиля (.bak-файлы). Вот только сам он, похоже, с ними ничего не делает ни при каких условиях. И если такая бяка произошла, то он просто создаёт новые чистые настройки, проигнорировав бэкап. Если плеер после этого закрыть, то старый бэкап мы больше не увидим - он просто перезапишется новым. И всё, куча настроек сделанных долгим трудом - потеряна. В такой парадигме, толку от этих бэкапов практически нет - а половина о них скорее всего даже не знает.

В общем, моё предложение - нужно заставить эти бэкапы всё-таки работать средствами плеера. А именно: если файл настроек пустой, отсутствует, или заполнен нулями, или имеет какие-то рандомные нечитаемые данные - то нужно автоматом восстанавливать предыдущие настройки из тех самых .bak-файлов. И всё: проблема любых сбоев решена. Потому что указанные состояния файлов - это 100% повреждение (если бы юзер сам захотел почистить профиль, то он бы удалил и бэкапы, или вовсе всю папку).

[Artem]

отсутствует

Вот в этом случае они и используются.

А вообще для важных данных нужно резервные копии делать

[Alex-D]

Вот в этом случае они и используются.

Выходит, только одном из этих случаев, а все описанные выше остаются уязвимыми. Причём случай с отсутствием куда менее реалистичен, т.к. вряд ли какая-то системная ошибка приведёт именно к удалению файла. По сути, можно было изменить алгоритм проверки на просто "важные настройки считаны -> иначе восстановление бэкапа". Это бы перекрыло вообще все сценарии с глюками без нужды в них разбираться.

[Artem]

Причём случай с отсутствием куда менее реалистичен

С чего вдруг? Вообще говоря, Windows при проверки диска на ошибки такие файлы сама подчищает. Получается, что либо ОС не поняла, что диск поврежден, либо вы не дали его ей проверить.

[Alex-D]

С чего вдруг? Вообще говоря, Windows при проверки диска на ошибки такие файлы сама подчищает. Получается, что либо ОС не поняла, что диск поврежден, либо вы не дали его ей проверить.

Проверка диска запускается если только система отмечает ошибки выполнения каких-то операций. А это происходит далеко не во всех случаях. Если к примеру зависают операции ввода-вывода, то система вообще ничего не может до ручной перезагрузки, а потом лишь скажет, что завершение было аварийным. Физического или программного повреждения диска тоже может не быть - например, выбило в BSOD из-за кривой программы, а в это время шла запись файла. Так что надеяться на средства Windows сильно не универсально. Универсально - это убедиться плеером, что настройки считаны. Не сложнее проверки наличия файла, по сути. Зато насколько эффективнее.

[Artem]

AIMP делает как: сначала настройки пишутся в файл AIMP.new, затем (если все прошло гладко), AIMP.ini переименовывается в AIMP.bak, а AIMP.new в AIMP.ini. Делается это атомарной (почти) командой Windows ReplaceFile. Собственно, этот механизм и призван защищать от случайного выключения питания или BSODа при записи файла.

[Artem]

Ну проверку на пустой файл настроек я могу добавить, да только вероятность такого события крайне мала, так же, как и появлению нулей (там же мусор может быть, а не нули)

[«G-Li†ch»]

В моём случае бывали и нули, но начинались они с "выравненного по 4кб" смещения. Причём такие повреждённые файлы остались и после "неисправленных ошибок" диска — внезапно потушило сам комп прямо во время проверки (будто бы «винда испугалась» какого-то неожиданного ответа от HDD и внезапно решила вырубить комп), причём в журнале событий даже "про ошибки контроллера" или "неверный блок на устройстве" в момент "выключения" не появилось… Даже в System Volume Information\ отсутствовал свежий ChkDskДата.log (фактически, даже не узнать, с каким конкретно файлом произошёл сбой)…
И хорошо, что многие идентификаторы (в десятичном представлении) некоторых повреждённых файлов (к сожалению, не всех) были скопированы заранее в текстовый документ на другой раздел заранее (понимая, что строк командной строки от найденных повреждений может не хватить)… Десятки дней ушло на ручной поиск тех файлов, т.к. chkdsk выдаёт десятичные номера только из нижних разрядов идентификаторов, а fsutil требует полноценный идентификатор (включая и «непонятно откуда берущиеся флаги»)… Хорошо, что хотя бы альфа-версия Everything 1.5 имеет столбец идентификаторов файлов, но, к сожалению, прямо во время сканирования MFT в журнале событий появляются ошибки, да и с тех пор любая версия Everything перестала обнаруживать все файлы на диске (вместо полутора миллионов стало находить в разы меньше — файл базы данных раньше был около 70 Мб, а теперь даже меньше 30 Мб)…

[Artem]

Попробуйте эту сборку:
https://disk.yandex.ru/d/AKLYlHUCW9vT9Q

[Alex-D]

Ну проверку на пустой файл настроек я могу добавить, да только вероятность такого события крайне мала, так же, как и появлению нулей (там же мусор может быть, а не нули)

В моём случае не так уж и мала - стандартно несколько раз в год случалось, причём на разных ПК. И ни разу не запустилась проверка диска после этого. А насчёт случайных данных - тут хз, у меня в таких случаях именно нули. Видимо как-то связано с контроллерами самих жестких дисков. Но тогда тем более проверка нужна не на "пустой файл", а на отсутствие в нём настроек плеера, или хотя бы одной произвольной [секции] или key=value. В этом случае без разницы, что произошло с файлом и чем он заполнен. Нет настроек, значит нужно восстановить бэкап.

сначала настройки пишутся в файл AIMP.new, затем (если все прошло гладко), AIMP.ini переименовывается в AIMP.bak, а AIMP.new в AIMP.ini.

Ни разу в таких случаях не видел файов *.new, зато любой хоррор всегда попадал именно в ini-файлы.

Попробуйте эту сборку: https://disk.yandex.ru/d/AKLYlHUCW9vT9Q

Что именно следует проверить?