Profile access errors (was Re: Profile include support)

[Nicolas Williams]

On Mon, Aug 23, 2010 at 05:54:54PM -0400, Greg Hudson wrote:
> A relatively non-controversial thing to do would be to make
> profile_init() return EACCESS or EPERM if it saw one of those errors
> when failing to read any profile file.  I guess I'll do that for now.  I
> feel like the error-handling semantics here are very muddy, though; I'm
> not at all convinced that the proper response to "I had an access error
> reading one but not all configuration files" is to soldier on with the
> ones you can read.

That is: no profiles could be read and you got EACCESS while trying to
read one?  That'd be the default profile.

Considering the ability to work in a zero-conf manner I think even this
will be controversial (e.g., I don't like it).

Why not return extended error information as... special profile
relations in profile_t?

One relation could list the files read.  Another could list the files
not found (ENOENT) and another could list the files with access or
permission denied (EACCES, EPERM).  On profile write these relations
have to be left out.

BTW, what happens with include and profile writing?  Does the written
profile preserve the include directive or does it write the entire
profile including the included sub-profile contents?

Nico
--