Июньское обновление Windows принесло баг, который сложно назвать катастрофой, но легко назвать раздражающим: при окончательном удалении файла из Корзины система показывает не исходное имя, а внутренний служебный идентификатор вроде $Rxxxxx.ext. Для тех, кто в IT отвечает за поддержку рабочих мест, тестирование апдейтов и доверие пользователей к платформе, такая ошибка Windows важна не сама по себе, а как еще один симптом проблем с качеством.
О проблеме 19 июня сообщил The Register. Сбой проявляется в довольно узком, но понятном сценарии: пользователь удаляет один объект из Корзины без возможности восстановления, Windows показывает диалог подтверждения, и вместо привычного имени файла в нем внезапно всплывает внутреннее обозначение объекта. При этом в самой Корзине имя отображается корректно, а если восстановить файл, его исходное название тоже остается на месте. То есть ломается не хранение, не восстановление и не удаление как таковое, а именно последний экран подтверждения, где система неожиданно решает показать свои внутренности.
С практической точки зрения баг косметический. Он не удаляет лишние данные, не портит файловую систему и не превращает рабочую станцию в кирпич. Но именно такие мелочи чаще всего бьют по восприятию надежности сильнее, чем кажется разработчикам. Пользователь не обязан знать, что за $Rxxxxx.ext скрывается удаляемый им документ, таблица или архив. Для него это выглядит как системная невнятность: ОС просит подтвердить удаление файла, но не может нормально назвать сам файл. В корпоративной среде это быстро превращается в тикеты уровня «после обновления Windows показывает абракадабру», а дальше время уходит уже у сервис-деска, админов и команд, которые разбирают, баг это, локальный сбой или очередной привет от Endpoint-защиты.
Отдельно раздражает реакция Microsoft. Формально у компании есть обходной путь, но публично она его не раскрывает. В материале сказано, что этот вариант доступен только если организация обращается в Microsoft Support for business. Всем остальным предлагают стандартную формулу: исправление готовится и будет включено в одно из будущих обновлений Windows. Для enterprise-клиентов это знакомый стиль общения, но он плохо работает в случаях, когда проблема пусть и не критичная, зато массовая и заметная. Если баг уже признан, пользователи обычно хотят видеть либо понятный workaround, либо конкретный срок, а не дипломатичное «resolution is in progress».
Здесь важен и тайминг. По данным The Register, проблемное обновление вышло 9 июня 2026 года, а публикация о баге появилась через десять дней, когда до следующего Patch Tuesday оставалось еще несколько недель. Иными словами, окно ожидания вполне ощутимое: сбой известен, он официально зафиксирован, но быстрое исправление вне очередного цикла не анонсировано. На этом фоне даже мелкая ошибка Windows работает как напоминание, что ежемесячные апдейты Microsoft по-прежнему несут не только патчи, но и сюрпризы. Тем более что речь идет не об одной-двух экзотических конфигурациях, а о широком охвате версий.
Список затронутых систем выглядит внушительно. Баг касается настольных версий Windows от Windows 10 Enterprise LTSB 2016 до Windows 11 26H1, а также серверных редакций от Windows Server 2012 до Windows Server 2025. Сам по себе сценарий с Корзиной на сервере не самый типичный сюжет дня, но широта матрицы поддержки важна. Когда один и тот же дефект проходит через такой набор релизов, это обычно вызывает неудобные вопросы к тестированию общего кода, регрессиям и критериям выпуска. Если ошибка воспроизводится на длинном ряду версий, значит, проблема не выглядит как локальная аномалия одной сборки.
Контекст для Microsoft здесь тоже не самый удачный. The Register прямо связывает этот эпизод с более широкой дискуссией о надежности Windows. В статье напоминают, что глава Windows Паван Давулури ранее говорил о работе над повышением надежности программного обеспечения Microsoft. На словах курс понятен: меньше неожиданных сбоев, больше предсказуемости, чище апдейты. На практике рынок видит привычную картину: то пользователи жалуются на сбои OneDrive, то обсуждают Blue Screen, то ловят очередной дефект после кумулятивного обновления. На таком фоне даже визуальный баг с Корзиной становится не смешной мелочью, а еще одной зарубкой на тему «обещали стабильнее».
Почему это важно не только пользователям
Для разработчиков и ИТ-руководителей в этой истории нет прямой технической драмы, зато есть несколько вполне прикладных выводов. Во-первых, подтверждается старая истина: оценивать обновления Windows только по списку security-fix'ов уже давно недостаточно. Даже если патч не ломает бизнес-критичные процессы, он может ухудшать пользовательский опыт в самых базовых сценариях. Во-вторых, мелкие регрессии особенно неприятны там, где компания пытается стандартизировать рабочие места и снизить нагрузку на поддержку. Один непонятный диалог в системе, установленной на тысячи машин, быстро становится вполне материальной операционной проблемой.
Для команд, которые администрируют парк Windows-устройств, это еще один аргумент в пользу поэтапного развертывания обновлений, контрольных групп и нормального окна наблюдения после установки. Да, баг в диалоге удаления не тянет на заморозку всего июньского патча. Но он хорошо показывает, почему даже рутинные апдейты нельзя воспринимать как безусловно безопасные. Сначала пилот, потом сбор обратной связи, потом масштабирование. Этот процесс всем надоел, но альтернатива обычно выглядит хуже: массовое развертывание, неожиданные жалобы и срочное объяснение бизнесу, почему привычная операция удаления файла теперь сопровождается загадочным кодом вместо названия документа.
Есть и более широкий инженерный аспект. Пользовательский интерфейс в операционных системах должен скрывать внутреннюю механику, а не демонстрировать ее без спроса. Когда служебное имя объекта прорывается в обычный UI, это не просто косметика. Это сигнал, что где-то на стыке системной логики и интерфейсного слоя оказался непродуманный или недостаточно протестированный сценарий. Для конечного пользователя это выглядит мелко. Для продукта масштаба Windows это выглядит как дефект дисциплины выпуска.
Пожалуй, главный вопрос здесь не в том, насколько вреден конкретный баг с Корзиной, а в том, почему Windows по-прежнему регулярно поставляет такие мелкие, но публично заметные поломки. Когда платформа с десятилетиями истории и огромной телеметрией продолжает спотыкаться о базовые сценарии интерфейса, разговор о надежности перестает быть маркетинговой темой и становится вопросом производственного качества.