Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - zsolt

#61
Espionage 3 / Re: iCloud Document folder sync mount point
November 17, 2016, 07:26:05 AM
Hello I did not test it, but yes, it should work as long as iCloud sync does not try to "follow" the mountpoint and sync the content of the disk image "through" the mountpoint folder, but if you did not see it so far, then I guess it will not sync it.

Only make sure that you lock the folder on one Mac before unlocking it on the other.

If you encounter any problems, let me know and we can test and compare

Zsolt
#62
Perfect. Now we need to replace the current Library/Application Support/com.taoeffect.Espionage3 folder with the one you found.

Quit espionage

Hold down the option key, and from the Finder's go menu, select Library, this will take you into the appropriate library folder. Now go to application support, and rename the com.taoeffect.Espionage3 folder to something else, and put the one you found into the same folder

Launch Espionage and the folders should be listed.

Now depending on changed paths, if you try to unlock a folder it might complain that the mountpoint folder is missing.
If this happens, create an empty folder using Finder with appropriate name and in appropriate location. Now click onto a small "i" near the folder name in the Espionage folder list and in the folder option window use the mountpoint drop down menu to point Espionage to the newly created folder.

Now with the mountpoint problem fixed, it might complain that the disk image is missing, at the same window in Espionage there will be another drop down menu named Disk image, note the current disk image name, then use the drop down menu to point Espionage to the same disk image but in the new location.

After this all should start to work

Let me know how it went,

Zsolt
#63
Hello, if you do not have a copy of your Library/Application Support/com.taoeffect.Espionage3 folder from the time Espionage worked, then the data is lost.
From your description I do not know if you have in dropbox only the mountpoint folder or the disk images or both, but if you do not have the Espionage database from the aforementioned folder, then we are missing the passwords to unlock the disk images, so again, we cannot do anything with the data.

If you have a copy of the folder, then let me know and we can set it up.

Rgds
Zsolt
#64
Espionage 3 / Re: "There isn't enough free space"
November 10, 2016, 04:32:27 AM
Thanks for letting me know, we are at mercy of the Sierra's  hdiutil.

I'm glad it works now, thanks for your patience and tests.

Strange though that a small folder worked.

Cheers
Zsolt
#65
Espionage 3 / Re: "There isn't enough free space"
November 08, 2016, 03:40:51 AM
Hello, it does provide me with info but it still does not make sense.

The disk image is somewhat bigger then the amount of data you want to protect, but we are talking MBs, not more, so 35GB folder to protect should not take up much more space. You will need double the space though, because we will put the original data in the trash and the disk image will grow to 35GB due to pasted data, but again, we are talking 70GB, few more MBs, still far from any limitation.

Furthermore, what you tried was a good way of thinking, and should have worked (although I do not have the numbers..) but let me explain: the disk image we create will have the 10x capacity in comparison to the size of the folder you are about to protect. So if you are protecting a folder of 1GB we will create a disk image with 10GB capacity (not size!, capacity, the size will be similar to the amount of data you put it, as mentioned before).

So I would expect it to work unless you tried to put more then 10x amount of data, still, I think the minimum disk image capacity we create is 10GB.

So try to protect a folder which is 4 GB big, if that works, you should be able to add another 31 GB to it, can you try this (although this will still not tell us why it failed in the first place, but at least you will have a solution)

What is the amount of available space on your internal disk?
If you still have a protected folder in Espionage, click onto small "i" near the folder name and click onto disk image drop down menu, which path do you see?

Thanks
Zsolt
#66
Espionage 3 / Re: "There isn't enough free space"
November 07, 2016, 10:35:15 AM
Hello, we do have some issues with Sierra and Espionage when the folder you want to encrypt or unlock is on an external drive.
Your case is a bit specific, it is an external drive, but still it is a boot drive, and I'm not sure how will then hdiutil which is creating the problem here, behave.

May I ask you for a simple test, instead of 35GB folder, can you create one test folder inside your Documents folder, add a few files to it, and try to encrypt it with Espionage, let me know if it worked.

Thanks
Zsolt
#67
The Data folder is where the disk images are mounted, but it is a surprise to me that it does not scan mounted volumes.
But as long as it works fine we are all happy.
Thanks for letting us know.
Cheers
Zsolt
#68
Espionage 3 / Re: Incorrect Alert Wording
October 27, 2016, 02:13:05 PM
Thanks for sharing this info here. It is not a surprise that third party utilities allow this, Apple is simply playing safe.

Cheers
Zsolt
#69
Thanks
Zsolt
#70
Can you please disable sophos, reboot and see if you can reproduce the problem.

Thanks
Zsolt
#71
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
#72
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!
#73
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
#74
Espionage 3 / Re: Incorrect Alert Wording
October 04, 2016, 06:37:16 AM
Hello thanks for reminding us on this, we will correct the message

Rgds
Zsolt
#75
Espionage 3 / Re: Recovery of sparse bundles
September 22, 2016, 11:23:44 PM
Perfect, I like happy endings :-)

Zsolt