lör 2007-12-29 klockan 09:20 +0800 skrev Michael Clark: > > You would still suffer from the 1 second racing condition where you > wouldn't known if your stored ETag was up-to-date due to the mtime > resolution (for modifications made outside of WebDAV) forcing you back > into the current weak ETag situation.
Modifications made using direct filesystem access, in the same second as the last WebDAV update and only rewriting the file in-place without changing the length. > A correct implementation would have to regenerate the strong ETag for > all of these sub second occurring requests (which is counter intuitive > for a cached property and also very inefficient). No, but if direct filesystem access is allowed it would need to be able to detect that there has been a such access in the same second and invalidate the strong ETag. > The other proposals I've been reading seem to require saying that this > ETag is strong when we know that this it not guaranteed to be true - but > perhaps this should be up to the admin (DavETagIsolation dav-mods-only). filesystem metadata based on just size + inode + mtime is never a guaranteed change identifier. Nothing stops an in-place edit where the timestamp is kept. > We could use something like inotify (or pnofity [1]) to track these > files for the required 1 second duration (or for a longer duration if we > wished to cache the stat info and know for sure it was valid). For ETag the 1 second interval is sufficient. Another option would be to use a 1 second mandatory write lock, but that feels a little scary.. Regards Henrik
