On Tue, 2008-08-19 at 10:01 +1000, russell muetzelfeldt wrote: > On 19/08/2008, at 9:37 AM, Tom Jackson wrote: > > On Mon, 2008-08-18 at 15:38 -0700, Jeff Rogers wrote: > >> While I'd agree this is a bug in fastpath, the real problem is that > >> fastpath is being used at all in this case. > > > > I don't think it is a bug in fastpath. > > fastpath is making assumptions about what means something is the > "same file", and those assumptions are not consistent with unix > filesystem semantics - how is this not a bug? >
No, fastpath is making the exact same assumptions that any archive program would make, which is to record certain attributes at the time something is cached and then compare them with the same attributes at a later time. Unless you do a checksum or some other comparison, the cache system doesn't work very well for the intended purpose. > sure, the original use case that triggered this seems non-optimal, > and could be done in other ways that don't trigger the bug, but that > doesn't mean fastpath is behaving correctly... The "use case" is a bug. You can't violate the essential granularity of the support system and call it a bug. The granularity is: inode, size, timestamp. Now, if we could just slow down AOLserver so that this never happens, that would be a great fix. This is like claiming that a checksum collision is a bug. No, it is expected. We don't use things like checksums, or inode,size,time as a key as a guarantee of anything. They are a compromise, in other words, engineering. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
