From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4602F464.40109@conducive.org> Date: Fri, 23 Mar 2007 05:25:56 +0800 From: W B Hacker User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: 9pfuse-mounted files don't "work" (Mac OS X on Power) References: <6ec892cd0703212059p28e0b775ic0c91a52f1da1362@mail.gmail.com> <6ec892cd0703220440l704b71a5i78842b636657dd1f@mail.gmail.com> <6ec892cd0703221213j785f9e22vd722659bf84f7133@mail.gmail.com> <20070322195416.GI33600@kris.home> <4602EBA5.6060600@conducive.org> <6ec892cd0703221416s5dcf634es5a9a2d58fc81cfca@mail.gmail.com> In-Reply-To: <6ec892cd0703221416s5dcf634es5a9a2d58fc81cfca@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 2e4cb1ee-ead2-11e9-9d60-3106f5b1d025 Colin DeVilbiss wrote: > On 3/22/07, W B Hacker wrote: >> Is this installed on its own partition? And if so, how formatted? >> >> And if not, is the underlying fs the OS X default hfs/hfs+, or is it >> FAT or UFS? > > The OS is backed by just one disk, formatted with the OS X default, > but I'm not sure I see how that's relevant to the MacFUSE case... I don't expect that it is (relevant..) But as all my OS X is on BSD-style partitions and UFS-only, thought I might ask before trying it out, just in case that was a known-unworkable combo. As is the case with, for example, Virtual PC for Mac, despite it 'living' in container files. Won't be 'real soon', as I have native Plan9 Fossil/Venti with Inferno on a Core-D 2.8 GHz right next to the PowerBook, and would rather sort that one first. Thanks, Bill > >> Kris Maglione wrote: >> > I'd be interested in the debugging output for files that actually work. >> > Your initial debugging output shows an iounit of 0 on Ropen calls, and >> > if that's accurate, finding out why would be of some use. > > 3 files attached: > cat.works.txt: plumber gives accurate length, cat works as expected > tail.works.txt: plumber gives accurate length, tail works as expected > tail.screwy.txt: plumber hacked to return length of 1, tail gives > output that is exactly the same as cat, except that the second char > (the "l" in "plan9=/usr/local/plan9") is missing, as if it were > "superseded" by the "p" from the length-1 read. > > Colin