Volume unmounts, sparse bundle image does not eject (DT 3 beta1)

My databases are in a sparse bundle, which is password protected. When I open a database in DT3 I am asked for the sparse bundle password, following which the volume is mounted and the database opens.

When I close the database the volume is unmounted (and as such is no longer visible in Finder), but the disk image is not ejected. As such, when I want to re-access the database, the volume is mounted without the password being required. To secure the sparse bundle, I have to open Disk Utility and manually eject the disk image.

This would seem to be inappropriate behaviour, because the unmounted volume is unprotected; I can no longer eject the disk image, because the volume is not visible in Finder after it has been unmounted. This leaves me at risk of leaving the disk image unprotected. DT2 did not unmount the volume on closing the database, and so did not have this problem. Ideally I would like DT3 to eject the disk image rather than unmounting the volume, certainly if the disk image was mounted by an action triggered by DT.

Ideas?

Does rebooting the computer fix this? What’s the extension of the sparse bundle?

Are you referring to an encrypted database created in DEVONthink or just putting a database in an encrypted sparsebundle disk image?

@cgrunenberg: I will have to get back to you on that; what I can say is that the problem is not solved permanently by rebooting the computer. I’m OOO, but will check tomorrow to see if I can verify whether rebooting temporarily alters the situation. Bizarrely (and not reproducibly) the sparsebundle sometimes appears to eject completely after an interval after the drive has unmounted. The extension is .sparsebundle

@bluefrog: this is not an encrypted database created in DT (because DT2 didn’t offer that functionality) but rather it’s 4 databases in a single encrypted sparsebundle disk image. The problem I described is regardless of whether I open just one or several databases and then close all open databases.

Let me please say that DT-support (that’s you guys) is quite spectacular - I have seldom come across such a responsive company, so very interested in your product and your customers - even the little ones. In the past you have helped me quickly with silly little things which my own inexperience or incompetence hadn’t allowed me to address without help. Thanks for that - it is for that reason that I paid for DT3 before even installing it - the product and your support have earned it easily.

1 Like

Thanks! That’s very appreciated to hear!

The ejection of an encrypted disk image is up to the individual, not DEVONthink.
The ejection of the volume for our new encrypted database should be done automatically (and I just confirmed it’s working as expected here).

Whilst I understand, what is happening makes it very difficult to eject the disk image - because the drive is unmounted, the disk image no longer appears in the Finder as a drive, and can only be ejected via Disk Utility (if you’re not sure what I’m trying to say, I’ll attach some screen shots from Disk Utility tomorrow). If DT is not to eject the disk, it should do nothing rather than half the job, with the other part left hidden. I kinda guess this is a side effect of DT being able to eject it’s own encrypted images.

However, that is probably a reasonable solution: use DTs own encrypted images. I don’t want to transfer my current databases to new ones before DT3 exits beta as I’m slightly worried about loosing data and not immediately noticing, making reverting to a working database difficult.

If DT is not to eject the disk, it should do nothing rather than half the job, with the other part left hidden.

I’m not sure what you’re referring to here. I have used an encrypted sparsebundle disk image for finances (note to self: you have a bill to pay today :stuck_out_tongue: ), and DEVONthink has never unmounted the volume after I’ve closed the database.

I’ll post some screenshots tomorrow pm, together with a step by step instruction. Perhaps in the meantime you could send me your finances database and I’ll see if that works :smiley:

:stuck_out_tongue: Not much exciting in it, for sure! :wink:

As DEVONthink 3 can automatically mount such volumes, it also tries to unmount & eject them after closing the database.

As DEVONthink 3 can automatically mount such volumes,

I was referring to DEVONthink 2.x. I haven’t moved my financial database to 3.x at this point. :slight_smile:
Sorry for the confusion @Blanc, @cgrunenberg

@BLUEFROG: not to worry - DT2 didn’t manage volumes, and DT3 does, which is brilliant - or would be :wink:
@cgrunenberg: here are the steps I take and two images explaining what I mean:

In the favorites I have 4 databases listed. All 4 are located in a sparsebundle named Database.sparsebundle. The sparsebundle is password protected.

I open one of the databases by double-clicking the name in the favorites. A system dialog box requests the password to access the sparsebunde. I enter the password, click ok, the database is loaded into DT3.

Disk Utility shows the status seen in image 1.

I now close the database by right-clicking the name of the open database in the list of open databases and choosing close database.

Disk Utility shows the status seen in image 2.

The disk image is not fully ejected. If I now open any database contained in the sparsebunde I am not asked for the password again. Only once I eject the “Apple sparse bundle” from Disk Utility (remember: the “Apple sparse bundle” does not appear in Finder, whereas “Database” does, until it is ejected by DT and becomes grey in Disk Utility) do I need to re-enter the password when opening a database.

This is not resolved by restarting the computer.

Image 1:
Image%201

Image 2:
Image%202

1 Like

This might be a bug of 10.14.x, DEVONthink tells macOS to both unmount & eject the volume and the system claims that the operation was successful, even if the device was only unmounted but not ejected.

Somethings tells me Apple won’t be as responsive as you guys… if I can provide any further details which aid you in identifying the problem or filing a report with Apple, please let me know.

We could reproduce this but didn’t have time to investigate this more - too many other things to check due to the amount of feedback.

I fully understand that and appreciate the mad volume of work you must be seeing at the moment - I noted Jim answering posts on Sunday (don’t forget work-life balance guys, looking forward we’re still going to need you in the years to come). Perhaps you have a list of “things to do when everything has calmed down” which you could pop this bug on. I feel I don’t have the technical expertise to report this to Apple in a useful way but at the same time see a degree of risk to your users who assume safe ejection where there is none.

Thanks again for all your time, patience and love to your product!

1 Like

Just an update: I have now observed the same behaviour when ejecting an external SSD connected via USB to SATA. On ejecting the volume is unmounted (and so disappears from Finder), but the disk is not ejected. It actually only ejects when I cut power to the USB-SATA-docking station. If I try to insert any other disk into the docking station before forcing an eject in this way, then it is not recognised. I didn’t observe this behaviour with an HDD in the same docking station.

I guess that confirms this to be a macOS problem (I’m now on 10.14.5, nothing has changed in this respect from 10.14.4).

Thanks for the info!

Oh, Apple… I still love you but… sigh :stuck_out_tongue: