I'm lost. If you are interested in serving the same content, mtime tells you the last time the content was modified. ctime changes for reasons all unrelated to the content.
But this is a cache, which is a copy. There is never any way to guarantee that the content is the same as what is currently on disk, unless you compare the files directly. Of course that totally negates the purpose of the cache. If this is what you want, you should disable the cache completely. BTW, if you just delete the fastpath config parameters from the config file fastpath will be disabled, so it is disabled by default right now. I'm also wondering if the inode/dev key just catches hard links. I think it also works via indirection with symlinks? Both stat and open follow symbolic links, so the inode is probably more stable than the filename on unix. Anyway, trying to guarantee anything about files is a lost cause. tom jackson On Thu, 2008-08-21 at 12:46 -0700, Jeff Rogers wrote: > Titi Alailima wrote: > > > what you were looking for. Even with the mtime fix there's no > > guarantee that systems which muck around with mtime (such as tar) > > won't cause separate files to collide. For a contrived example: > > I think the best you can do is to use ctime instead of mtime, or maybe > btime on *bsd. You can still run into problems if you have clock skew, > but there's only so much you can account for. -- 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.
