tags:

views:

306

answers:

4

I cannot use the Resource File API from within a file system plugin due to a PlatSec issue:

*PlatSec* ERROR - Capability check failed - Can't load filesystemplugin.PXT because it links to bafl.dll which has the following capabilities missing: TCB

My understanding of the issue is that:

File system plugins are dlls which are executed within the context of the file system process. Therefore all file system plugins must have the TCB PlatSec privilege which in turn means they cannot link against a dll that is not in the TCB.

Is there a way around this (without resorting to a text file or an intermediate server)? I suspect not - but it would be good to get a definitive answer.

+3  A: 

The Symbian file server has the following capabilities:

TCB ProtServ DiskAdmin AllFiles PowerMgmt CommDD

So any DLL being loaded into the file server process must have at least these capabilities. There is no way around this, short of writing a new proxy process as you allude to.

However, there is a more fundamental reason why you shouldn't be using bafl.dll from within a fileserver plugin: this DLL provides utility functions which interface to the file servers client API. Attempting to use it from within the filer server will not work; at best, it will lead to the file server deadlocking as it attempts to connect to itself.

I'd suggest rethinking that you're trying to do, and investigating an internal file-server API to achieve it instead.

MathewI
+1  A: 

Using RFs/RFile/RDir APIs from within a file server plugin is not safe and can potentially lead to deadlock if you're not very careful.

Symbian 9.5 will introduce new APIs (RFilePlugin, RFsPlugin and RDirPlugin) which should be used instead.

Dynite
A: 

Tell us what kind of data you are storing in the resource file.

Things that usually go into resource files have no place in a file server plugin, even that means hardcoding a few values.

Technically, you can send data to a file server plugin using RFile.Write() but that's not a great solution (intercept RFile.Open("invalid file name that only your plugin understands") in the plugin). EDIT: Someone indicated that using an invalid file name will not let you send data to the plugin. hey, I didn't like that solution either. for the sake of completness, I should clarify. make up a filename that looks OK enough to go through to your plugin. like using a drive letter that doesn't have a real drive attached to it (but will still be considered correct by filename-parsing code).

Writing code to parse the resource file binary in the plugin, while theoratically possible, isn't a great solution either.

QuickRecipesOnSymbianOS
A: 

Theres a proper mechanism for communicating with plugins, RPlugin.

Do not use RFile. I'm not even sure that it would work as the path is checked in Initialise of RFile functions which is called before the plugin stack.

Dynite