Оптимизатор в Windows 10 2004 слишком часто дефрагментирует SSD-диски

Оптимизатор в Windows 10 2004 слишком часто дефрагментирует SSD-диски

Оптимизатор в Windows 10 2004 слишком часто дефрагментирует SSD-диски

С выходом Windows 10 2004, релиз которой состоялся 27 мая, утилита для дефрагментации дисков стала работать не совсем корректно. В частности, пользователей предупреждают о слишком частой дефрагментации SSD-дисков и сбоях в расписании оптимизации локального хранилища.

Вся эта функциональность в Windows 10 скрывается в соответствующем пункте настроек — «Безопасность и обслуживание». Там пользователи могут оптимизировать диски (дефрагментация, тримминг), проверять наличие обновлений и следить за безопасностью устройства.

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

Тем не менее команда WilderSecurity обнаружила неприятный баг. С выходом Windows 10 2004 утилита для оптимизации дисков не фиксирует дату последней дефрагментации. Таким образом, пользователь будет постоянно наблюдать соответствующее уведомление, требующее провести оптимизацию SSD-накопителя, даже в том случае, если эта операция осуществлялась в этот же день.

Думаю, многие помнят, что из-за особенностей SSD-дисков частая дефрагментация может ощутимо сократить срок службы такого накопителя.

Разработчики Microsoft уже устранили этот баг в тестовой сборке Windows 10 Insider Preview build 19551, теперь осталось дождаться, когда патч дойдёт до пользователей.

Claude освободил 700 ГБ, удалив домашнюю папку разработчика

Разработчик Себастьен Гиймо поручил ИИ-агенту Claude написать скрипт для очистки временных файлов. Бот справился слишком эффективно: удалил домашний каталог пользователя вместе с 700 ГБ данных и результатами недельной работы, но предусмотрительно оставил папку /tmp, ради которой всё и затевалось.

Гиймо регулярно запускает ИИ-агентов, которые оставляют после себя множество временных файлов.

Он попросил модель Claude Fable создать отдельную песочницу для каждого агента в /tmp и очищать её после завершения работы, не затрагивая используемые данные.

Первая версия скрипта показалась разработчику слишком сложной. Из-за наличия команд безвозвратного удаления Claude запустил дополнительную проверку безопасности. Система Anthropic сочла задачу рискованной и автоматически понизила модель сначала до Opus 5, а затем до Opus 4.8.


Новая модель написала тест, который сравнивал цели удаления с /tmp и домашним каталогом пользователя. Обе директории были правильно признаны опасными. А затем начался этап очистки тестовых данных, и Claude повторно использовал ту же переменную, в которой находился путь к домашней папке.

Гиймо остановил процесс, но слишком поздно: агент успел удалить 700 ГБ. Большую часть информации разработчик восстановил из Git, конфигурации Nix, журналов сессий и других источников. Однако недельная работа всё же пострадала.

Разработчик предполагает, что автоматический переход на менее сильную модель мог повысить риск ошибки. Более производительная Fable 5, возможно, заметила бы конфликт переменных.

RSS: Новости на портале Anti-Malware.ru