From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 27 Mar 2007 09:19:45 -0400 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Fwd: Reading from FS with inaccurate file sizes? In-Reply-To: <1174682487.948169.40940@y66g2000hsf.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1174603052.290868.102400@n76g2000hsh.googlegroups.com> <1174611197.118455.89640@e1g2000hsg.googlegroups.com> <1174615620.140037.84140@o5g2000hsb.googlegroups.com> <1174671190.917580.16150@l75g2000hse.googlegroups.com> <1174682487.948169.40940@y66g2000hsf.googlegroups.com> Topicbox-Message-UUID: 33574df2-ead2-11e9-9d60-3106f5b1d025 When you cat >> file and file has zero length in stat, then the write happens at an offset of zero. This is perhaps the only time that the stat size should be used for a purpose other than returning from stat. Synthetic file systems tend not to care about the offset on writes anyway. There is another difference between > and >> on Plan 9: when the shell opens with > it includes OTRUNC; when it opens with >> it does not. This is enough of a hint for file systems that care. On Linux apparently things happen the other way around: O_TRUNC is never sent, but O_APPEND is sent for >> opens. MacFUSE doesn't send either, which is another bug I've filed: http://code.google.com/p/macfuse/issues/detail?id=132 MacFUSE also seems to employ some subterfuge where fds do not map one-to-one with FUSE file handles. Another bug I've filed: http://code.google.com/p/macfuse/issues/detail?id=133 To be fair, these are the kinds of mistakes I would expect any Unix-mindset implementation to make, and it surprised me quite a bit that Linux FUSE got so much of this right from the start (or at least from when I started using it). I wonder how many of these mistakes BSD FUSE makes. Russ