Messages

Thanks
Zsolt

Can you please disable sophos, reboot and see if you can reproduce the problem.

Thanks
Zsolt

Hello,

Thanks for your "live feed" on things happening, but it is a bit hard to follow you.....

Lets try to simplify it:
- do you have a virus scanner
- does the folder in Espionage unlock quickly (obviously not, that much I understood), if it eventually unlocks, if you lock and unlock again, does it work better? Can you try it few times?
- if you reboot, does it again face delay between unlock?
- what about hdiutil, does that work quickly (after reboot, if this is the reboot which makes the delay appear)
- this is the path you need to use in unmount /Users/DoctorX/Pictures/Stuff
so hdiutil unmount /Users/DoctorX/Pictures/Stuff should eject it, with a
mount
command you can check what is mounted

Zsolt

Hello J.D.

thanks for your input.

For us, the main task is to differentiate between Espionage problems and external utility problems, hdiutil in this case.
Espionage problems we can fix, external utility problems we cannot, just report.

When you unlock a folder, we call hdiutil with path to the disk image, moutpoint folder and password, the rest is done by hdiutil.
Once the folder is unlocked, it is all operating system which handles the communication between disk image content (native Apple data format) and application which is reading the data (quicktime in this case - again Apple's app)

The unlock-mount part, you can do without Espionage if you have all the info needed, here is how to get it:
- Apple's Terminal application has a nice feature of filling out file paths if you drag the folder or file over Terminal's window
- so first we will find the files in Finder and then we drag to have the paths filled in

- unlock espionage
- make sure the folder you will be testing with is locked
- click onto small anchor icon in the lower left corner of the Espionage window to keep the window open
- click onto small "i" near the folder name, this will take you to the folder options window
- here you will see two drop down menus, one for disk image another for mountpoint folder you will also see a copy password button
- click onto disk image drop down menu and just select the disk image with the mouse in the menu and let the mouse button go, this will open a finder window with the disk image selected
- do the same for the mountpoint folder
- now paste this into terminal:

/usr/bin/hdiutil attach

press space once to add a space char after attach word

drag the disk image over terminal window

hit space again, the write

-mountpoint

another space

drag the moutpoint folder over terminal window

hit space and write

-noverify -noautofsck -stdinpass -nobrowse

The complete command whould look like this:
/usr/bin/hdiutil attach /Volumes/PEROosxj/esptst.sparsebundle -mountpoint /Volumes/PEROosxj/mountpt -noverify -noautofsck -stdinpass -nobrowse

hit enter

you will be asked for a password, click onto copy password button in Espionage window, paste it into terminal, hit enter

if all good you will get a short report on mounted volume.

What is interesting to see is how quickly will this happen, will there be a delay or not?

note that espionage will not be aware that the image is mounted, i.e. it will not show the folder to be unlocked, this is normal as we did the things "behind" espionage.

To unmount the volume, you write in the terminal

hdiutil unmount volumepath

the volumepath you will get in the aforementioned report

####

To the slow reading, see if you get this slow reading effect also when you mount it by hand, but I'm positive you will....

Let me know how it went,

Cheers
Zsolt

P.S. we got one report with similar behaviour, and the culprit was in a virus scanner, if you have one, make sure you disable it while testing. Thanks!

Dear All,

So here is the final verdict on Sierra and failing folder opening:
Espionage uses encrypted sparse bundle disk images which are a data format provided by Apple's OS X. It is a clever and flexible approach of storing data safely. This is why we went that route and it worked fine for many years.
Apple also provides a command line utility to manage and manipulate those disk images, this utility is called hdiutil.

After troubleshooting the problem, it turned out that if we specify to the hdiutil a mountpoint folder path which is located on an external volume, then the hdiutil returns a "no mountable filesystem found" error in spite of all data being in good condition. It is sufficient to specify a mountpoint folder which is on the system disk and all starts to work fine.

The problem being in Apple's utility, we cannot do much more then report it to Apple. At which priority will Apple address this problem, we have no clue.

Till then there are two workarounds:
1. move the mountpoint to the system disk, as we suggested earlier
2. do the 1. but create a so called symlink on the external disk where the original mountpoint folder was located. This symlink is very similar to Alias of a folder in Finder, it is a folder which "points" to another folder. In this way you could access the content of the protected folder in a same way as before, although there would be two mountpoint folders, one real, on your system disk and one which would look as real, but would in fact be a link to the one on the internal disk. If you want me to send instructions how to create the symlink, let me know.

Thanks for your patience in this matter,

Rgds
Zsolt

Hello thanks for reminding us on this, we will correct the message

Rgds
Zsolt

Perfect, I like happy endings :-)

Zsolt

Hello, each encrypted folder has 3 pieces of information needed to work. The disk image, the disk image password and the mountpoint folder.
The mountpoint folder is least critical as it can be recreated easily.
The sparse bundle disk image and the password are however critical.
The password, name and location are all stored inside Encrypted Espionage database. The fact that the database shows the folder in the folder list, should mean that the database is OK. However, as Espionage tells you, the required disk image cannot be found in the recorded location.

So the first task will be to locate it, either on your current disks or in some backup if you have any.

To know what to look for, please click onto small "i" near the folder name, and in the folder option window the disk image drop down menu will tell you which disk image name is connected to that folder. Take a note about this name and this is what you have to find.

Once you found it, let me know.

I hope you find it,

Zsolt

We can reproduce the problem using Apple's hdiutil which we use for mounting, so it seems to be Apple's bug, we are currently investigating if we can circumvent this, but at the moment the only workaround we can offer is to move the mountpoint folder to a local disk. It is not a big deal though as the data is still on the external disk, but it requires a bit of manual work which is not what we want.

We will update as soon as we find some better way.

Rgds
Zsolt

And hello again and again....the other user we sent the beta to, reported that it did not help. However, we figured out that he is trying to unlock a folder which resides on an external disk. If this is true in your case too then please try the following:

​Can you please create an empty folder on your internal disk, in your Documents folder for example, then unlock espionage, click onto small "i" near the folder name, and in the folder options window use the mount point folder drop down menu to point Espionage to the newly created folder.
​Once you switched the mount point folder to the new one, try to unlock the folder again, let me know how it went
​
​Thanks
Zsolt

Hello again, I just realised that the link is broken...and the devs are offline (it is night over there) so we will have to wait a few hours, I will let you know as soon as I get a new link.

Sorry about this

Zsolt

Hello Jaldert,
​
​Here is a

https://www.espionageapp.com/other/builds/EspionageSierraBeta1.zip

​Would you be so kind to check if you can reproduce your problem with this beta build.
​
​Thanks in advance,

Zsolt

Hello Johannes, it is not entirely clear to me how could it put the disk image onto desktop if it complained a second before that it cannot reach it...but the most important thing is that the data is back. In a remote session I could probably explain what happened, but now we leave it as it is.

I'm glad you did not loose confidence in Espionage, I assume it was not an application problem, but then again, you never know.

If you have any doubts, please test with some noncritical data and proceed only after you are sure that it works as you expect it.

Thanks for your feedback

Zsolt

just prepare everything, anchor the window of Espionage, then record the time stamp and click onto unlock, when the error message pops up, record the time stamp, then copy all the messages out of all messages and system in console, this operation lasts maybe 2-3 seconds so you should not get to many.
The espionage messages show up with espionage header, but I guess they do not come, otherwise you would see them.

Thanks
Zsolt

Hello Johannes, would a remote session suite you, then we can take a look into this together. I'm GMT+2 and should be available at 9:45 PM my time i.e. in 3.5 hours, if you can and wish to do it, let me know and we connect.

Cheers
Zsolt