Безпечне видалення зовнішніх помилок USB-накопичувача через $ extension

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

Якось вікна завжди зберігають файли журналу відкритими: "Завжди", оскільки в цей час я лише підключив накопичувач, скопіював 10 Гб VM і хотів відключити його згодом (як, наприклад, 15 хвилин після копіювання, тому все копіювання було зроблено).

Як бачите, немає жодної іншої програми, яка б тримала ручку на диску, окрім System . Я спробував перезапустити explorer.exeтак само, як RemoveDrive.exeвід Uwe Sieber . Не пощастило, замки на жорсткому диску завжди залишаються.

Моє єдине рішення - це просто відключити його від мережі (тоді як я боюся пошкодити дані?) Або перезапустити комп'ютер (завжди допомагає, чи не так?).

Можливо, це має щось спільне зі мною лише на жорсткому диску 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-клавіші, також відображається як фіксований привід, хоча, здається, не виникає жодних проблем безцеремонно і без будь-яке безпечне видалення робиться, тому я здогадуюсь, що принаймні вимикає кешування запису через його швидкість і, можливо, щось інше, оскільки, як ніколи, ця проблема не виникає, завжди зберігаючи свою миттєву віддаленість. Це не обов'язково є ідеальним прикладом, оскільки я не був ретельним у своєму тестуванні (це просто анекдотичний характер), але це може пролити трохи світла на це через його «фіксованого» характеру, але очевидну відсутність сприйнятливості до цього питання. Просто їжа для роздумів.

<- Рішення ->

У будь-якому випадку, просто кажучи, вам потрібно відключити диск. Зробити це можна одним із двох способів. Примітка: Існують трохи коротші способи зробити це, але ось смішно ретельні кроки, оскільки я не знаю своєї аудиторії. Метод GUI на сьогоднішній день найшвидший, завдяки тому, що diskpart.exe не приймає комутатори або вбудовані команди / аргументи.

1. Графічний інтерфейс: Запустіть -> "diskmgmt.msc" -> Знайдіть свій диск у списку фізичних дисків (нижня панель) -> клацніть правою кнопкою миші диск (більшу частину зліва), а не розділ -> Клацніть "Офлайн"

Або:

2. CLI: запустіть -> "cmd.exe" -> введіть "diskpart" -> введіть "список диска", знайдіть свій диск # -> введіть "select disk x", де x - номер вашого диска з останнього кроку -> type "офлайн диск". Тепер ви можете вийти з командного рядка або просто ввести "exit" на diskpart, а потім закрити рядок.

Примітки:

• Все, що важливо, має бути в режимі офлайн-гучності, оскільки це призведе до усунення утримування NTFS на диску, але розміщення диска є більш простим і ретельним.

• Диск №s завжди однаковий між diskpart.exe і diskmgmt.msc, оскільки вони перетягують інформацію з того самого місця, на випадок, якщо ви цікаві / переживаєте / обережно.

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

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

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

Тому я закрив диспетчер завдань і Safe Remo працював.

Я створив цей пакетний сценарій, щоб "розблокувати" будь-який том. Просто запустіть сценарій .bat як адміністратор, виберіть гучність і натисніть ENTER. Після цього ви зможете використовувати "Безпечне видалення", як зазвичай, для від'єднання пристрою.

@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 і залишити два варіанти, ремонтуючи вручну. MBR або намагання використовувати програмне забезпечення, наприклад, MBR для відновлення, щоб мати можливість знову отримати доступ до диска, або використовувати програмне забезпечення типу gparted, щоб знову відформатувати диск і встановити нову таблицю розділів, де помилка, швидше за все, сталася.

Я вважаю, що ці файли належать до транзакційних NTFS (TxF).

Я чую, що Transactional NTFS використовується autoupdate, але не маю поняття, чому система хотіла б розмістити це на зовнішньому диску, а потім не зможе зупинити його при запиті безпечного видалення. Інформація про ресурс Fsutil не показує жодної активності.

Спробуйте на консолі cmd:

fsutil ресурс стоп E:

або, якщо це не допомагає,

fsutil ресурсу setautoreset вірно

і перезавантажити. Ви також можете спробувати зупинити послугу, пов’язану з TxF, в Управлінні комп'ютером / Сервісах

Нещодавно у мене було те саме, що відбувається з флешкою. Як і ви, я постійно показував активні ручки $ Extend і вважав, що вони заважають мені безпечно зняти диск. Я наткнувся на це питання і спробував fsutilпропозицію Сема безрезультатно . Що для мене працювало, це ручне відключення накопичувача. Оскільки моя флешка встановлена ​​як F:, я побіг:

mountvol f: /d

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

Я не знаю, чи справді це було для мене, але я додаю це на випадок, якщо це допомагає комусь іншому.