Re: [Chicken-hackers] chicken-fuse

[Evan Hanson]

Hi Jörg,

On 18/03/14 10:02, "Jörg F. Wittenberger" wrote:
> According to fuse.h " If the file does not exist, first create it with
> the specified mode, and then open it" I understand that the create
> procedure is supposed to return a file handle, not simply a error
> code.  That is the wrapper in fuse.scm should set the info file handle
> like this:
>
> (define-callback (fuse_create_callback (c-string path) (mode_t mode)
> (fuse_file_info fi)) int
>   (let ((v ((current-filesystem-callback 7) path mode)))
>     (fuse_file_info_fh_set! fi (object-evict v))
>     (callback-result 'create v)))
>
>
> With this change the code already works much better.  ;-)

Thanks so much for digging into this! You're right, and I've just
tagged a release with this fix. I hadn't previously tried to use the
handle resulting from a create call, but this is much better.

>> Nevertheless, I'm concerned with the inconsistent  related use of
>> fuse_file_info_fh's result.
>>
>> As far as I see it's only set in fuse_open_callback to the result of
>> object-evict of the users value.
>>
>> In fuse_release_callback it is used as - correspondingly - expected
>> by first calling object-unevict on fuse_file_info_fh's return value.
>>
>> However fuse_read_callback and fuse_write_callback both simply pass
>> the result up to the user code.  This strikes me as wrong, isn't it?
>
> These concerns remain valid IMHO.  Aren't they?

I'm unsure what's best. My thinking was that, because the release
callback is used to clean up resources, one would want it to receive the
handle value in a form that's already as cleaned up as possible from
fuse's point of view (i.e. unevicted). But you're right, this makes it
different from read and write, which use the evicted copy in order to
keep it in static memory (which is the whole point). *shrug* I dunno,
the eviction is pretty hacky anyway. If it needs to change, I think I
prefer your proposal of simply disallowing non-immediate handle values.

Evan