From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6ec892cd0703221213j785f9e22vd722659bf84f7133@mail.gmail.com> Date: Thu, 22 Mar 2007 13:13:18 -0600 From: "Colin DeVilbiss" To: 9fans@cse.psu.edu In-Reply-To: <6ec892cd0703220440l704b71a5i78842b636657dd1f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6ec892cd0703212059p28e0b775ic0c91a52f1da1362@mail.gmail.com> <6ec892cd0703220440l704b71a5i78842b636657dd1f@mail.gmail.com> Subject: [9fans] Re: 9pfuse-mounted files don't "work" (Mac OS X on Power) Topicbox-Message-UUID: 2e226e66-ead2-11e9-9d60-3106f5b1d025 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