Re: [Chicken-users] Curious about limitations of fuse egg, can't open a fossil on the hashfs example fuse fs.

[Evan Hanson]

Hi Matt,

Interesting, cool project. Here are a few guesses at your questions,
without having had a look at the specific steps to reproduce.

On 2016-09-19 22:24, Matt Welland wrote:
> 1. Can't open a fossil on hashfs:

I'd bet this is caused by SQLite trying to lock a file with flock(2),
which isn't implemented by hashfs.scm or, for that matter, by the egg
itself. I'd like to add support for flock callbacks at some point, but
even then you'd still need to extend hashfs.scm to do something
meaningful with that callback in order to get Fossil to work (assuming
I'm right about the underlying issue, that is...).

> 3. du -sh returns zero even for a non-empty directory.

There's a longstanding TODO in the egg relating to explicit blocksize
handling, and I'd bet money this is down to that. In short, the egg only
bothers to fill the st_size field of stat structs, leaving st_blksize
empty since there isn't really a block size associated with a synthetic
filesystem anyway. Usually this is fine since the size in bytes is
already provided and most tools will just use that (or assume 512 as the
block size, in some cases), but it might be that du(1) is taking that
empty field at face value and reporting odd sizes as a result. On Linux,
you can get du(1) to report the "real" size of a file (i.e. in bytes,
not blocks) with `du -b`, so in your example `du -bsh` *should* report
nonzero values for nonempty directories, unless there's something else
going on.

> 2. On hashfs Megatest compile gets through making the .o files but fails to
> link with an error:

This might be similar to #3. I may have a go at fixing that TODO soon,
and if I do I'll let you know -- I'd be curious to see if that is indeed
the cause.

Cheers,

Evan