I’ll offer the following naive comments. I could be way wrong. There’s too little public information about Sookasa, particuarly about Sookasa for iOS, to be sure. Sorry the following is so verbose.
My guess is that this isn’t a bug, but rather has to do with Sookasa’s implementation on iOS (iPhone, iPad) and iOS’s sandboxing (secured segregation) of files on an application by application basis.
The very limited amount of info I can find about Sookasa, particularly with regard to Sookasa for iOS, seems to suggest that it is focused on single file at a time and that access to Sookasa encrypted files must first be initiated within the Sookasa app (via built-in Open In choice of application). This is different than in Mac OS X or PC Windows, where the Sookasa app/client is presumably permitted to insert itself between DropBox and apps. and/or is allowed access to most all files regardless of associated app.
Issues I would guess are involved:
- iOS doesn’t allow Sookasa to insert itself between Scrivener and DropBox or between Scrivener and iOS when Scrivener accesses files.
- On iOS, it seems that Sookasa requires an explicit request from the user, on a file by file basis, to decrypt/access files. The problem is, a Scrivener project isn’t just the .scrivx file inside the project folder, but rather the project folder and all subfolders and numerous files within it. I’m guessing that Sookasa would only decrypt and allow access to just the explicitly requested .scrivx file. So even if one were to launch the Sookasa app and tell it to launch the .scrivx file via its internal Open In feature, the remaining subfolders and numerous other files will likely remain encrypted and inaccessible.
You might try launching the Sookasa app and asking it to open the project’s .scrivx file via Open In using Scrivener, but I’m guessing the most you’ll see is the binder, but not document contents, and that may be accompanied by one or more error/security messages. Scrivener typically has constantly changing numerous files (binder/index, multiple .rtf documents, etc.) open simultaneously.
My guess is that Sookasa gets around the per application sandboxing of files by spinning off an unencrypted temporary copy, which is what actually gets opened by its internal Open In (i.e. made available to the app specified in Open In. And subsequently reencrypting and recopying that temporary copy back into Sookasa’s vault.
You might contact Sookasa’s tech support and ask them if it can handle simultaneously making numerous files in multipe subfolders available to a single iOS app. A parallel would be whether it could do such for something like a database comprised of multiple table and index files (think multi-file oriented apps like dBase, Microsoft Access, SQL, etc. rather than single file oriented apps like Word, Excel, etc.). You might also try creating a small Scrivener project containing at least a few folders and several small/short documents, compressing/zipping that, sending it to them and see what they say or suggest.
A wild guess, given iOS’s per app file segregation, it might be that Sookasa would have to convince DropBox to include a Sookasa component within the DropBox for iOS app, so that it’s activity happens within DropBox, invisible to iOS and Scrivener.
Hope the above is reasonably accurate and of some assistance.
That’s more than I know. I’ll shut up.
