On 3/22/07, Colin DeVilbiss wrote:
> This was silently dropped the first time.


As was mentioned off-list, this was wrong; sorry for the noise.

I made an interactive test that let me independently open, read, and
close the file. Opening the file generated all of the traffic I
expected, but a subsequent read didn't drive any traffic to 9pfuse.

After I saw that, I implemented an accurate length for the rules file
in src/cmd/plumb/fsys.c:/^dostat (using printrules and strlen), and
reads started working.

On a whim, I just went back and changed the code to set the length to
1 for rules and 0 for everything else, after which "cat" and "head"
worked, but things like "tail" and "less" behaved rather badly.

MacFUSE must be making decisions about the "actual" filesize based on
the stat value, and changing the behavior of read() accordingly.

Makes me wonder how any other "I'm not sure how big this really is"
virtual filesystems handle this in MacFUSE...or maybe all of the
existing successful ones are just "passthrough" types that have
accurate file sizes because the data's already built somewhere with
the size available.

If anyone else has already gone down this path, I wouldn't mind
hearing about it, on-list or off.

Colin DeVilbiss