Secara aman menghapus drive USB eksternal gagal karena $ extended


26

Saat menghubungkan hard drive USB 3.0 eksternal ke port USB 3.0 saya, saya tidak pernah dapat menghapusnya dengan aman.

Entah bagaimana windows selalu membuat file jurnal tetap terbuka: masukkan deskripsi gambar di sini "Selalu" seperti saat ini saya hanya menghubungkan drive, menyalin VM 10GB dan ingin melepaskannya setelah itu (seperti 15 menit setelah menyalin, jadi semua penyalinan telah selesai).

Seperti yang Anda lihat, tidak ada program lain yang menangani disk selain Sistem . Saya mencoba memulai kembali explorer.exejuga RemoveDrive.exedari Uwe Sieber . Tidak beruntung, kunci pada hard drive selalu tetap.

Satu-satunya solusi saya hanya mencabutnya (sedangkan saya takut merusak data?) Atau me-restart komputer (selalu membantu, bukan?).

Mungkinkah ada hubungannya dengan saya hanya memiliki hard drive SSD dan disk eksternal adalah drive biasa? Mungkinkah ada hubungannya dengan driver USB 3.0 (NEC Electronics USB Hub)? Saya tidak pernah mengalami masalah ini saat menggunakan port USB 2.0 biasa.

Ada ide tentang cara melepas disk dengan benar?


Jika salah satu dari jawaban ini adalah solusinya, jangan ragu untuk memilih atau menandai sebagai jawabannya.
user88311

Jawaban:


25

Saya datang dengan mencari penjelasan yang mungkin atau cara yang lebih mudah (baca: otomatis / skrip) untuk menghapus "kunci" ini pada metadata MFT / TxF / NTFS. Kupikir aku akan membuang ini di luar sana, karena aku punya solusi yang bekerja untukku dalam situasi yang tak terhitung jumlahnya. Saya telah menggunakannya untuk menghapus segala jenis drive USB dan eSATA yang macet seperti ini. Masalahnya tampaknya terutama drive yang dapat dilepas yang dipasang sebagai drive tetap, seperti yang ada di dock eSATA atau penutup USB. USB thumb drive umumnya tidak menunjukkan masalah ini untuk saya.

Catatan tentang perbedaan terakhir ini: Sandisk Extreme USB 3.0, binatang aneh yang terdiri dari pengontrol SSD di badan kunci USB, juga muncul sebagai penggerak tetap, meskipun sepertinya tidak ada masalah yang ditarik begitu saja dan tanpa setiap penghapusan yang aman dilakukan, jadi saya kira setidaknya mematikan caching tulis karena kecepatannya dan berpotensi hal lain juga, karena sepertinya tidak pernah memiliki masalah ini, selalu mempertahankan kepindahannya yang instan. Bukan berarti contoh yang sempurna, karena saya belum teliti dalam pengujian saya (ini hanya anekdotal) tetapi mungkin sedikit menjelaskan hal ini karena sifatnya yang "tetap", namun kurangnya kerentanan terhadap masalah ini. Hanya makanan untuk dipikirkan.

<- Solusi ->

Bagaimanapun, cukup cantumkan, Anda harus offline drive. Anda dapat melakukan ini dengan satu dari dua cara. Catatan: Ada beberapa cara yang lebih pendek untuk melakukan ini, tetapi ini adalah langkah-langkah yang sangat teliti karena saya tidak tahu audiens saya. Metode GUI sejauh ini adalah yang tercepat, karena fakta bahwa diskpart.exe tidak mengambil switch atau in-line perintah / argumen.

  1. GUI: Jalankan -> "diskmgmt.msc" -> Temukan drive Anda di daftar disk fisik (panel bawah) -> klik kanan drive (bagian paling kiri), bukan partisi -> Klik "Offline"

Atau:

  1. CLI: Jalankan -> "cmd.exe" -> ketik "diskpart" -> ketik "disk daftar", temukan disk Anda # -> ketik "pilih disk x", di mana x adalah disk Anda # dari langkah terakhir -> ketik "disk offline". Sekarang Anda dapat keluar dari command prompt atau cukup ketik "exit" di diskpart, lalu tutup prompt.

Catatan:

  • Semua yang penting harus offline volume karena ini akan menghapus penahanan NTFS pada drive, tetapi menguraikan disk lebih sederhana dan lebih menyeluruh.

  • Disk #s selalu identik antara diskpart.exe dan diskmgmt.msc karena mereka menarik info dari tempat yang sama, kalau-kalau Anda penasaran / khawatir / waspada.


1
Rook, ini terlihat hebat. Tidak sabar untuk mencoba. Dan ya, ini selalu terjadi dengan drive tetap untuk saya - biasanya drive eksternal hosting VM. Satu pertanyaan tetap: Setelah mengatur drive eksternal offline lalu apa? Cabut saja kabelnya? Hapus dengan aman?
Dennis G

Ini berhasil untuk saya.
hattenn

Ini terlihat bermanfaat, terima kasih. Jawaban oleh @elieux paling sederhana jika hanya Task Manager yang menyebabkan masalah.
Reg Edit

Hanya meninjau kembali beberapa pertanyaan lama, dan saya memeriksa tautan ke Uwe Sieber yang dihapusrive.exe yang Anda catat, dan saya merasa itu akan berhasil melalui mekanisme yang sama (menguraikan dan menurunkan cukup dekat dalam hal implikasi praktisnya, yang pertama menjadi untuk drive fisik (ditiru atau tidak, seperti volume iSCSI) dan yang terakhir untuk partisi / volume yang terpasang (yaitu C :, X: dll) ... tidak yakin tentang seberapa mirip mereka bekerja di bawah lembaran) jika Anda menggunakan opsi "-e". Sesuai petunjuk yang dihapusrive.exe.exe: "" [-e] mencoba turun dan mengeluarkan jika penghapusan gagal ""
Rook

Terakhir, sepertinya Uwe Sieber sendiri menjelaskan dasar-dasar mekanisme yang berperan pada kode / API dan tingkat kesalahan: codeproject.com/Articles/13839/…
Rook

10

Hari ini, saya terpikir untuk melihat log peristiwa. Saya menemukan ini tepat setelah upaya penghapusan:

log: Sistem, sumber: Kernel-PnP, ID peristiwa: 225, level: peringatan

Aplikasi \ Device \ HarddiskVolume2 \ Windows \ System32 \ Taskmgr.exe dengan proses id 6436 menghentikan penghapusan atau ejeksi untuk perangkat [...]

Jadi saya menutup Task Manager dan Safe Remove berhasil.


Luar biasa! Ini memecahkan masalah bagi saya. Sekarang mengapa Microsoft tidak bisa memasukkan informasi itu dalam dialog yang mengatakan "program" masih menggunakan drive!
Reg Edit

Hebat, ini memecahkan masalah bagi saya juga. Windows 10. Ditemukan bahwa saya memiliki Taskmgr di Autostart. Jadi, mengapa Taskmgr mengunci drive USB?
weberjn

meskipun offlining (lihat jawaban rook) dan hal-hal fsutil telah bekerja di masa lalu untuk saya, hari ini tidak. ProcessExplorer mengira itu hanya "sistem" yang melakukan penguncian. Bagaimanapun, EventViewer menunjukkan penyebab yang sama dengan Anda (TaskManager), jadi saya menutupnya dan saya menjadi emas.
mpag

5

Saya membuat skrip batch ini untuk "membuka" volume apa pun. Cukup jalankan skrip .bat sebagai administrator, pilih volume, dan tekan ENTER. Setelah itu, Anda harus dapat menggunakan "Hapus aman" seperti biasa untuk melepaskan unit.

@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%

Skrip ini didasarkan pada saran @Rook, sehingga digunakan diskpartuntuk membuat disk offline. Ketika ini dilakukan, semua pegangan ditutup secara paksa. Perbedaan dalam skrip ini adalah ia membuat disk kembali online, sehingga dapat dikenali saat berikutnya terhubung ke sistem.


Manis! Belum pernah menggunakannya tetapi saya menghargai inisiatif Anda dalam mempermudah orang lain ... Saya telah mendapatkan beberapa utilitas lain yang memberikan lebih banyak informasi (yaitu Hotswap !: mt-naka.com/hotswap/index_enu.htm ) tentang drive yang dapat dilepas / diperbaiki daripada windows bawaan, tetapi belum menemukan solusi berbasis offline yang cepat dan kotor, jadi ini hebat!
Benteng

3

Sebagian besar dari drive eksternal / Windows OS combo memiliki masalah ini, mungkin sebagian besar.

Apa yang saya lakukan adalah tidur kotak saya (laptop) dan tunggu sepuluh detik yang diperlukan untuk drive eksternal untuk mematikan (saya bisa mendengarnya). Kemudian cabut.

Jika sistem tertidur maka semua operasi I / O selesai & bus I / O dihentikan. Menunggu drive untuk mematikan adalah "sabuk dan suspender" di atas itu.

(Perhatikan bahwa jika seseorang terlalu paranoid untuk pendekatan itu, melakukan hibernasi harus cukup. Daya penuh tidak seharusnya diperlukan.)


Sebuah solusi, tetapi itu harus berhasil.
Dennis G

1

Untuk saat ini Anda dapat mencoba untuk melepaskan koneksi eksternal dengan mematikan komputer dan mencabutnya, oleh karena itu mencoba kehilangan data dan kemudian mengaturnya agar mudah dihapus untuk mencegah kehilangan data ketika hanya mencabutnya tanpa melepasnya.

Sejujurnya itu terdengar seperti kesalahan MBR di mana drive macet melihat dirinya selalu terpasang, dalam hal ini jika Anda mencabut drive saat dihidupkan Anda dapat merusak MBR dan meninggalkan Anda dengan 2 pilihan, memperbaiki secara manual MBR atau mencoba menggunakan perangkat lunak seperti perbaikan MBR untuk dapat mengakses drive lagi, atau menggunakan perangkat lunak seperti gparted untuk memformat disk lagi dan mengatur tabel partisi baru di mana kesalahan paling mungkin terjadi.


"lalu mengaturnya agar mudah dihapus" <- dapatkah Anda menjelaskan apa yang Anda maksud? Bagaimana saya tahu bahwa drive berpikir itu selalu terhubung, yaitu tidak menjadi drive USB eksternal?
Dennis G

Sambungkan drive Anda lagi setelah dihapus dalam keadaan mati dan komputer telah dinyalakan kembali, properti, perangkat keras, klik drive, properti, kebijakan, optimalkan penghapusan cepat. EDIT: Dalam pertanyaan Anda, Anda menyatakan bahwa itu sebenarnya USB drive eksternal.
user88311

Dalam kebanyakan kasus, sistem menginstal drive eksternal dengan set flag "penghapusan cepat". Dan, saya rasa, pengaturan ini seharusnya membuatnya "sangat tidak mungkin" bahwa mencabut drive saja akan menimbulkan masalah.
Daniel R Hicks

1

Saya percaya file-file ini milik Transactional NTFS (TxF).

Saya mendengar Transactional NTFS digunakan oleh autoupdate, tetapi tidak tahu mengapa sistem ingin menempatkan ini pada disk eksternal dan kemudian tidak dapat menghentikannya atas permintaan penghapusan yang aman. Info sumber daya Fsutil tidak menampilkan aktivitas apa pun.

Coba di konsol cmd:

perhentian sumber daya fsutil E:

atau, jika itu tidak membantu,

fsutil sumber daya setautoreset benar

dan reboot. Anda juga dapat mencoba menghentikan layanan terkait TxF di Manajemen / Layanan Komputer


Ini hal yang sangat menarik! Saya akan memeriksanya pada saat itu terjadi.
Dennis G

2
Tapi ... tidak berhasil. Ketika menjalankan fsutil resource stop <drive:>sysinternals handle.exetidak menunjukkan pegangan. Jadi mereka dihapus, tetapi ketika saya kemudian mencoba untuk menghapusnya dengan aman, pegangannya kembali ke tempat semula.
Dennis G

0

Saya memiliki hal yang sama terjadi dengan flash drive baru-baru ini. Seperti Anda, saya terus menunjukkan $ Extend handle yang aktif dan menganggap mereka mencegah saya melepaskan drive dengan aman. Saya menemukan pertanyaan ini dan mencoba fsutilsaran Sem tidak berhasil. Apa yang berhasil bagi saya adalah melepas drive secara manual. Karena flash drive saya dipasang sebagai F :, saya berlari:

mountvol f: /d

Saya kemudian mencabut drive, memasangnya kembali, menggunakan kembali mountvol f: <volumename>dan menggunakannya untuk sementara waktu. Ketika saya selesai, saya memeriksa pegangan yang aktif dan melihat $ Memperpanjang entri yang sama yang saya perhatikan sebelumnya. Ketika saya mencoba melakukan penghapusan aman 'normal', itu berhasil meskipun pegangan aktif.

Saya tidak tahu apakah ini semata-mata kesempatan ini bekerja untuk saya, tapi saya menambahkannya di sini kalau-kalau itu membantu orang lain.


Saya pikir $ extended stuff adalah herring merah - ada beberapa alasan lain yang mencegah Windows turun dari drive.
Daniel R Hicks

Setuju, realisasi itu adalah alasan terbesar saya memposting jawaban ini. Saya telah mengejar $ memperpanjang masalah tanpa tujuan, dan menemukan bahwa pegangan itu tidak menyebabkan masalah dengan penghapusan yang aman. Saya hanya berharap semenjak ikan herring merah itu membawa saya ke pertanyaan ini, mungkin jawaban ini akan membantu nelayan sial berikutnya :).
ajk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.