Windows 10: How to safely remove an external drive?

In layman's terms it just means that if the drive is done reading or writing it is done. Unplugging the drive will not corrupt any files or the file system. It may make some Windows processes that won't give it up angry, but it won't harm anything on your disk.

I will try and find the info on the recycle bin when I have more time.
It does not cause the Safely Remove problem as far as I recall.

 

Found it.
Back in Windows 7 days, I had a problem with a corrupted recycle bin. Every time I started the PC I got the message: "The Recycle Bin on X:\ is corrupted. Do you want to empty the Recycle Bin for this drive?", where X: was usually my external drive's letter that was not connected.
While this was going on I was unable to safely remove the external drive, always had to just unplug or restart the PC. Solving the Recycle Bin corruption problem also seemed to have cleared up the Safely Remove item. I thought that the corruption was caused by leaving deleted files in the recycle bin and unplugging the external (my opinion). The recycle bin is controlled from the desktop and Windows keeps track of those files so they can be restored.

Anyway, I sort of recalled that problem and thought I would throw it out there just in case. While you do not have a corruption, you might want to clear the bin with the external connected and see if that does anything. Can't hurt, might help.

 

Thank you very much.

Yes, cannot hurt, that sounds very plausible, very good idea to mention that bin issue here. I have the "savely remove" probleme with many or all of my drives, I am not quite sure at the moment. But especially for the last one there seems to anything wrong with its bin so I will try to repair it.

The bin:




Contained in the bin:




The contend and / or the bin itself cannot be deleted, do not know why, so may be there is a connection.

I would think one can disconnect a dirve anyway - like the message is saying - when this option is enabled, but why is the error message appearing all the time:

 

I'm a hardware guy, I understand the devices and how to work with them.
But when it comes to the inner workings of the Windows operating system I must defer to others on this forum, who are much more knowledgeable than I on that.

Here is an easy way to check things: Connect the external drive > copy a few random files to the drive > delete the files > go to Recycle Bin and Empty it.
Then see if you can Safely remove. If not, shut down the PC (not restart) > remove the drive > start the PC.
See if that clears anything up.

If you want to just rebuild the Recycle Bin just to eliminate that as a possibility then see here:
Corrupted recycle bin - Windows 10 Forums

 

Curious if you have tried setting the removal policy on Best Performance?

 

Thank you very much.

I will try all that the next time I can use that drive again.

I have always had problems to safely remove a drive, so this option was activated a long time ago the last time. I am just wondering if I had really understood it right, I had understood to activate "Quick removal" to get the drive safely removed, now. Or should I have activated "Best Performance"? The last one I did not tried again.

 

You choose Best Performance to enable write caching, which means you will/should use the Safely Remove feature before removing the drive.

You choose Quick Removal when you do not want to use the Safely Remove feature.

 

Yes, but why did you ask: Curious if you have tried setting the removal policy on Best Performance?

 

Because it wasn't clear (to me) whether that had been done.

 

Alright, I understand.

Just had the same probleme with another drive, it couldn't be removed safely.




There obviously were two recycle bins on it. After some tries / error messages



I made it to remove the bins.





Suddenly I could remove that drive safely.

 

Very cool.
Hope it works for the other drive too.

 

Yes, very strange, so obviously the bins indeed have a connection to these error messages (how should one know that), so your idea to mention that was absolutely great.

Thank you very much

 

@Enter and @TV2: Sorry, I'm also not set up for email notification. Very interesting discussion since my last post.

A few additional thoughts/questions ...

Hmmm... I don't know and I can't figure out how to replicate or create something similar on my system, I suspect because I don't have the 'Operation' column in Process Explorer. I've never seen that column before, and I can't figure out how to activate it on my Win7 system. How did you get it to display? (Is it perhaps only available in Win10?)

Do those FreeCommander P:\ line entries have any associated handles if you open handles in the lower pane (Ctrl+H)? When you see this kind of entry after FreeCommander is closed, does a Process Explorer search (Ctrl+F) for 'P:\' find any open handles associated with FreeCommander? If not, then it doesn't seem like deleting/closing the P:\ line entries would be necessary before removing the external USB drive.

I haven't previously noticed handles like the AIMP.exe handles shown here (without the drive P\: in the handle Name, and with 'Section' as the handle Type). Do those handles close if you close AIMP?

At any rate, I'm guessing they are not relevant to the inability to safely remove the external USB drive, as it appears you searched for "P:" rather than "P:\", and those handles were found because they include "P:" in the handle Name (AIMP:MouseHookShare and AIMP:KeyboardHookShare).

Without researching it further (which I don't have time or energy to do right now), I'm still not 100% certain what produces the ...$Extend\$RmMetadata\$Txf handles. I previously mentioned from recollection of my research a few years ago that these handles are associated with NTFS journaling, but if I remember correctly, commenters in some forums/blogs thought they might be associated with Windows Indexing or Recycle Bin. My best recollection is that after sifting through everything I could find, I was about 90-95% certain the culprit was/is NTFS journaling.

I've since forgotten much of what I learned at that time, but this MSDN blog post by Raymond Chen (Jan 1, 2013) seems to explain the relevant basics of NTFS journaling in regard to removing an external USB drive. If I understand it correctly, the journaling is the first of several steps whenever changes are made to a file on an NTFS drive, and "provides file system recoverability by logging ... operations required for any transaction that alters important file system data structures ... before these operations are carried through on the disk" (e.g., before all other steps necessary to complete copying/altering/deleting a file). File data loss/corruption problems can occur if an external USB drive is removed before all the other steps are completed. As you obviously already understand, with write caching enabled, it is possible that the remaining steps may not actually be completed when the OS informs the user that the copying is complete, as the file changes cached in RAM may not yet written to the removable drive (presumably depending on how busy the OS is, data transfer speed, etc.). So their could be data corruption if the drive is unplugged before those steps are completed.

But disabling write caching is supposed to avoid such problems, so file operations are supposed to be complete when the OS tells you they are complete:
"Write-behind caching is disabled by default on removable drives. You get into this mess only if you override the default. And on the dialog box that lets you override the default, there is a warning message that says that when you enable write-behind caching, you must use the Safely Remove Hardware icon instead of just yanking the drive."
It seems to me that if journaling is the first step in any file-system change, then once you can be confident the other steps involved in file changes are completed, obviously no further journaling is necessary and the drive can be removed. Basically, as I understand it, journaling protects the file system structures (preventing file system corruption), while disabling write-caching protects the data contents inside those already protected file system structures (preventing file data corruption due to premature unplugging).

So my reasoning is that *IF*, in fact, the ...$Extend\$RmMetadata\$Txf handles are created/used by NTFS journaling as I have surmised, then "yanking the drive" with those journaling handles still open shouldn't cause any problems, as long as you verify other handles are closed and you have allowed enough time for all other file operations to complete. (Usually should be a few seconds at most, but pretty cautious and I figure I'm safe if I've waited 10-15 minutes.)

...But this reasoning hinges on whether I'm correct about the source of the ...$Extend\$RmMetadata\$Txf handles.

Given the ubiquity of external USB drives and the frequency of the ...$Extend\$RmMetadata\$Txf handles problem, it has always seemed strange to me that Microsoft has not (AFAIK) at a minimum:

• authoritatively clarified the issue, so users can be confident about what is going on (Is it NTFS journaling?)
• provided some guidance on 'safe' practices or workarounds (Is it 'safe' to unplug if those are the only open handles?)

...But I don't think those minimums are actually sufficient (especially since most average users would never see them or probably understand them. Instead, if these ...$Extend\$RmMetadata\$Txf handles are, in fact, associated with journaling, it seems to me Microsoft should build into Windows some way of automatically closing the handles when the user attempts to "Safely Remove Hardware and Eject Media", or provide a GUI option to do so, if/when that is the only issue preventing safe removal.

This reminds me that when I previously researched this, there was also some discussion in the Everything Search forum about whether NTFS indexing by Everything Search might be preventing external USB drive removal (and maybe something about whether Everything made use of the ...$Extend\$RmMetadata\$Txf handles ???). I don't recall the issues clearly right now, but I think there were some suggestions about how to tweak the Everything NTFS Index settings that seemed to make sense. ...But IIRC correctly I tried the suggested remedies without success.

I can see that this refers to what appears to be a Recycle Bin (S-1-5-21-263......), but any chance you could post an English translation of the first 5 lines?

Ohhh, very interesting!!!

Did you check what happened to the ...$Extend\$RmMetadata\$Txf handles in Process Explorer after you deleted the $Recycle.bin? ...I'm assuming they must have been closed/gone, but I'm trying to understand if deleting the $Recycle.bin closed the handles. If so, maybe they don't have to do with NTFS journaling, or perhaps NTFS journaling and Recycle Bin interact somehow (???)

I'm glad you've been looking at this so closely and willing to put so much time into researching it and posting your results, as it's a very frequent and vexing problem, and it would be nice to get a clearer understanding. I put a couple questions in boldface and blue above to make them easier to pick out. Like I said earlier, I'm not set up for email notification, but I'll try to check back regularly for the next few days to continue our discussion if you have anything further to post.

 

'Operation' is a default column in ProcMon (that is Process Monitor as in the screen shot - not Process Explorer). If you mean ProcMon and you don't have the 'Operation' column you can add it by going to Options > Select Columns.

As for unplugging drives I have the same issue with the journal apparently locking volumes but I couldn't ever figure it out. It is more of a problem for me disconnecting the (SATA) disk in my docking station than USB but happens with both.

I use a shortcut to sync.exe pinned to the taskbar to flush everything to disk and then just disconnect.

 

Hello gdv.

It is "Process Monitor", not "Process Explorer". May be "Process Monitor" is not that reliable, I do not know.

I could not reproduce that display at the moment, I assume since "Process Explorer" didn't show those handles there indeed were not such.

Yes, but forcing to close such a line would have the same effect, I assume, as just plugging off the drive, the risk of data loss / data loss.

This now is "P Explorer". If I remember it right, yes, after Aimp has been closed these entries were gone.

Yes, I would assume that, too.

Yes, those meta data are caused / used by the NTFS, I would say.

Yes, or if a handle is close by force, I guess.

Yes, and / or besides of process belonging to that special transfer, there might be other processes, e.g. rebuilding / changing the NTFS, the Journal or whatever.

Yes, that's why one has to click "safely remove" to write the content of the cache to the drive. Actually I would assume, flushing the cache would have the same effect, but the error message keeps on popping up.

Yes, sounds plausible.

Yes, sounds like a reasonable assumption, of course, but if not...one never knows, not only that a single file might get corrupt, if the NTFS breaks...

Or watching if the LED of the drive is still blinking, I could imagine.

Or rather do some programming (or what ever) to solve the problem.

Ooops, the best search program I know, may be it was me asking that. Everything would not cause failing savely removing, it would automatically close or release such handles to let the drive be safely removed.

Yes, of course:

Access to folder denied.
Admin rights needed to process.
You have to get the rights from admin to make changes to the folder.

Date of creation.
Button, left: Try again and "Cancel", right.

If I remember it right, they disappeared.

I would assume, the Journaling / NTFS works the same way for bins like it / them does with normal files.

Yes, that's great, thank you.

That one I use, too. But it is just flushing the cache, it does not effect / stop the journaling, NTFS actions, I would say. This one can be used, too: FFB.zip