Безопасное извлечение внешнего USB-накопителя не удается из-за $ extension

При подключении внешнего жесткого диска USB 3.0 к моим портам USB 3.0 я никогда не смогу безопасно удалить его.

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

Как видите, нет другой программы, хранящей дескриптор диска, кроме System . Я попытался перезагрузить, explorer.exeа также RemoveDrive.exeот Уве Зибер . Не повезло, замки на жестком диске всегда остаются.

Мое единственное решение - просто отключить его (тогда как я боюсь повредить данные?) Или перезагрузить компьютер (всегда помогает, не так ли?).

Может ли это иметь какое-то отношение ко мне, имея только жесткий диск SSD, а внешний диск - обычный диск? Может быть, это как-то связано с драйверами USB 3.0 (NEC Electronics USB Hub)? У меня никогда не возникало этой проблемы при использовании обычных портов USB 2.0.

Любые идеи о том, как правильно размонтировать диск?

Я пришел, чтобы найти возможное объяснение или более простой (читай: автоматизированный / скриптовый) способ очистить эту «блокировку» метаданных MFT / TxF / NTFS. Думал, что я это выброшу, потому что у меня есть решение, которое сработало для меня в бесчисленных ситуациях. Я использовал его для удаления всевозможных USB и eSATA дисков, которые вот так застряли. Проблема, по-видимому, заключается, прежде всего, в съемных дисках, которые монтируются как фиксированные диски, например в док-станции eSATA или в корпусе USB. USB-накопители, как правило, не показывают эту проблему для меня.

Примечательно, что это последнее различие: Sandisk Extreme USB 3.0, странный зверь, состоящий из контроллера SSD в корпусе USB-ключа, также отображается как фиксированный диск, хотя, похоже, нет никаких проблем с его извлечением без церемоний и без любое безопасное удаление выполняется, так что я предполагаю, что оно по крайней мере отключает любое кэширование записи из-за его скорости и, возможно, чего-то еще, поскольку, похоже, эта проблема никогда не возникает, всегда сохраняя свою мгновенную возможность удаления. Не обязательно идеальный пример, так как я не прошел тщательное тестирование (это просто анекдотично), но это может пролить немного света на это из-за его «фиксированной» природы, но при этом очевидной недостаточной восприимчивости к этой проблеме. Просто пища для размышлений.

<- Решение ->

В любом случае, проще говоря, вам нужно отключить диск. Вы можете сделать это одним из двух способов. Примечание: есть несколько более короткие способы сделать это, но вот нелепо тщательные шаги, потому что я не знаю свою аудиторию. Метод с графическим интерфейсом является самым быстрым из-за того, что diskpart.exe не принимает переключатели или встроенные команды / аргументы.

1. GUI: Выполнить -> «diskmgmt.msc» -> Найти диск в списке физических дисков (нижняя панель) -> щелкнуть правой кнопкой мыши диск (самая левая часть), а не раздел -> нажать «Автономно»

Или:

2. CLI: Выполнить -> «cmd.exe» -> введите «diskpart» -> введите «list disk», найдите ваш диск # -> введите «select disk x», где x - это номер вашего диска с последнего шага -> type "автономный диск". Теперь вы можете выйти из командной строки или просто набрать «exit» на diskpart, а затем закрыть приглашение.

Заметки:

• Все, что важно, это отключить том от диска, так как это устранит удержание NTFS на диске, но отключить диск проще и тщательнее.

• Дисковые # всегда одинаковы для diskpart.exe и diskmgmt.msc, потому что они извлекают информацию из одного и того же места, на случай, если вы любопытны / обеспокоены / осторожны.

Сегодня мне пришло в голову посмотреть в журнале событий. Я нашел это сразу после попытки удаления:

журнал: система, источник: Kernel-PnP, код события: 225, уровень: предупреждение

Приложение \ Device \ HarddiskVolume2 \ Windows \ System32 \ Taskmgr.exe с идентификатором процесса 6436 остановило удаление или извлечение для устройства [...]

Поэтому я закрыл диспетчер задач и Safe Remove сработал.

Я создал этот пакетный скрипт, чтобы «разблокировать» любой том. Просто запустите скрипт .bat от имени администратора, выберите том и нажмите клавишу ВВОД. После этого вы сможете использовать «Безопасное удаление», как обычно, для отсоединения устройства.

@echo off
@cls

set tempfile="%TEMP%\diskscrp.dsk"

echo.
echo   === Disk removal tool ===
echo.
echo   Select the disk volume number
echo   (if the disk has multiple volumes, select any of them)
echo.
echo list volume | diskpart | findstr /C:Volume /C:---
echo.
set /p volume="   Selected volume: "
echo.

echo select volume %volume% >>%tempfile%
echo offline disk >>%tempfile%
echo online disk >>%tempfile%

diskpart /s %tempfile% | findstr /C:"not valid"

if "%ERRORLEVEL%"=="1" (
  echo   Disk has been unlocked successfully.  Try to safely remove it now.
)

del /F %tempfile%

Этот скрипт основан на предложении @Rook, поэтому он используется diskpartдля отключения диска. Когда это сделано, все ручки принудительно закрываются. Разница в этом сценарии заключается в том, что он автоматически переводит диск в оперативный режим, поэтому его можно распознать при следующем подключении к системе.

Большая часть комбо внешнего диска / ОС Windows имеет эту проблему, может быть, большинство.

Что я делаю, это сплю свою коробку (ноутбук) и подожду десять секунд, пока внешний накопитель выключится (я слышу это). Затем отключите.

Если система находится в спящем режиме, то все операции ввода-вывода завершены, и шина ввода-вывода отключена. Ожидание отключения питания - это "ремень и подтяжки".

(Обратите внимание, что если кто-то слишком параноидален для такого подхода, спящий режим должен быть полностью достаточным. Полное отключение питания не требуется.)

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

Честно говоря, это звучит как ошибка MBR, когда диск застревает, видя, что он всегда подключен, и в этом случае, если вы отключите диск при включенном питании, вы можете повредить MBR и оставить 2 варианта, восстанавливая вручную. MBR или попытка использовать программное обеспечение, такое как восстановление MBR, чтобы иметь возможность снова получить доступ к диску, или использовать программное обеспечение, такое как gparted, для повторного форматирования диска и установки новой таблицы разделов, в которой, скорее всего, произошла ошибка.

Я считаю, что эти файлы принадлежат Transactional NTFS (TxF).

Я слышал, что транзакционная NTFS используется автообновлением, но я понятия не имею, почему система захочет поместить это на внешний диск, а затем не сможет остановить его по запросу безопасного удаления. Информация ресурса Fsutil не показывает никакой активности.

Попробуйте в консоли cmd:

fsutil остановка ресурса E:

или, если это не поможет,

fsutil ресурс setautoreset true

и перезагрузите компьютер. Вы также можете попробовать остановить службу, связанную с TxF, в разделе «Управление компьютером / Услуги».

У меня тоже самое было с флешкой в ​​последнее время. Как и вы, я продолжал показывать активные маркеры $ Extend и предполагал, что они мешают мне безопасно удалить диск. Я наткнулся на этот вопрос и попробовал fsutilпредложение Сэма безрезультатно. У меня сработало ручное размонтирование диска. Так как моя флешка была смонтирована как F :, я запустил:

mountvol f: /d

Затем я отключил диск, снова подключил его, перемонтировал с помощью mountvol f: <volumename> и использовал некоторое время. Когда я закончил, я проверил активные маркеры и увидел те же записи $ Extend, которые я заметил ранее. Когда я попытался сделать «нормальное» безопасное удаление, оно оказалось успешным, несмотря на активные маркеры.

Я не знаю, был ли это чистый шанс, что это сработало для меня, но я добавляю это здесь на случай, если это поможет кому-то еще.