Ejecting encrypted USB Drive only unmounts not ejects?

[FumbleDuck]

Hi All,

Just a little obeservation I made this afternoon. I have an external USB drive and when formatted normally (MacOS Extended), ejecting it from the desktop unmounts the volume AND ejects the drive (sends some kind of power down signal from what I can gather). This means the drive spins down, mine also blinks the LED, and I know its OK to remove the drive.

However, since formatting the drive as encrypted, "ejecting" the drive only unmounts the volume but does not power down the drive. If I wait for a couple of minutes then the drive does power down but I suspect this is more to do with the manufacturer firmware settings than MacOS.

In this situaton the only place I can see where I can actually "eject" the drive and send the power down signal is by right clicking on the drive (not volume) in Disk Utility and selecting Eject. This only works when the volume has already been ejected already (unmounted).

Not a big problem but I dont like yanking out the USB cable with the disks still spinning (even though no volumes are mounted). It doesnt sound good as the drive makes a little squeak and a click as the motor stops and I assume the head slams back into its rest position?? As far as I can tell this is safe to do but I still would prefer not to.

So my question is why does encrypting the drive mean that MacOS can no longer unmount AND eject but just unmount? I much prefer the eject action to do both. Re-formatting the drive back to non-encrypted returns the normal behaviour.

I've tried various terminal commands to see if anything different happens and also the eject option within Alfred but with no luck. Any ideas?

Cheers.

 

[treekram]

I had noticed this before but didn't put 2 and 2 together to make the connection between it being an encrypted drive vs. an unencrypted one. It may very well be not due to the encryption per se but Core Storage (which is used with the current FileVault). My understanding is that modern HDD's have a spring which puts the heads back in a safe position when power is lost. So that's what you're probably hearing. I noticed today that if you select the "Put hard disks to sleep when possible" setting in System Preferences and wait long enough, that will turn off the encrypted drive - of course if you eject it, it will power it up again! I can't make any statements about HDD longevity in not powering down the drive before disconnecting it. I have an encrypted HDD which has started to exhibit issues when running a disk scanning program (slow reading of certain sectors) but can't attribute it to not being powered down because it's a Toshiba drive and I've had issues with the only other Toshiba drive I had and because it spent most of it's life as a non-Core Storage drive and since being encrypted, it's only been used on a very sporadic basis (it's off-site backup and the sectors that are slow are beyond where the backup data is).

 

[FumbleDuck]

I did wonder if it might be something to do with Core Storage as I see that gets invoked during the formatting process. How it changes things I dont know though.
To be honest I might see if I can use Automator in some way to auto-mount an encrypted *.dmg file (or maybe a veracrypt volume) on a standard formatted drive. At least that way I know the drive will be properly powered down before disconnecting.

 

[treekram]

Personally, I don't think not turning off the drive when ejecting is a big deal.

However, if you want to do the power-off, and I respect people's decisions in that respect, I don't know if a encrypted .dmg is the best answer. I would be more afraid of the .dmg getting corrupted and losing information than I would be of a hard drive dying prematurely because of how the power is turned off. Do you find going into Disk Utility a pain? If so, I think an automated script (to double-eject, not to facilitate using an encrypted .dmg) is a better option. If that doesn't work, just about all Disk Utility functions can be executed on the command line (Terminal) and shell scripts can be made executable via the Finder. If you're not familiar with that would work, post a response.

 

[treekram]

I should clarify that my reservations with an encrypted dmg file becoming corrupted pertains to read-write dmg's. I have used read-only encrypted dmg's to store personal documents that were scanned for years now without problems.

In digging down deeper into this, when a disk is encrypted, it becomes two devices for the OS - one is the Core Storage device, the other is a logical HFS device. The unmount that is done in the Finder or the first unmount in the Disk Utility unmounts the logical HFS device. After this, if you do an eject in Disk Utility, it ejects the Core Storage device. One should not eject the Core Storage device before unmounting the HFS device (this can be done through Terminal, not the Finder or Disk Utility). I did this and when I plugged the HDD back in, at first it didn't mount the HFS device. I had to unplug it and re-plug it for the OS to do the normal mount procedure. (For HDD's, I think unmount and eject are synonymous but those were the commands that I used so that's why the different terms are used.)