Henrik Nordström wrote:
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.
That would be a reasonable limitation - hence the suggesion for a
DavETagIsolation dav-only (the default being a more conservative dav+fs)
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.
AFAICT, we are in agreement here. My point was related to the current
inability to detect the direct filesystem access i.e. with the
DavETagIsolation dav+fs you would have to invalidate the ETag unless you
had some sort of mechanism to detect sub second direct filesystem
accesses (or mandatory locking as you propose) - i.e. invalidate strong
ETag == regenerate strong ETag.
Assuming direct filesystem access is not allowed then a stored ETag with
mtime+inode+length+modification counter would be guaranteed to be enough
(yes, it would need to be stored due to the additional counter) as
mod_dav would be the only one changing anything.
Alternatively, a PUT without Content-Range (the common case) could be
changed to mktemp / open / write / close / rename - this may remove the
need for storing anything as a normal PUT would always change the inode
(it would catch most of the common cases - excluding direct filesystem
modification within the same second or mmap changes which don't update
mtime and PUT with Content-Range which I think is a pretty special case?).
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.
Yes but in the first paragraph you are excluding these sub second file
system access anyway :) . Excluding sub second direct file system access
and with the addition of a modification counter it would be enough? (or
by making PUT without Content-Range change the inode).
The isolation levels should perhaps be discussed independently as this
is leading to some of the confusion. Here is my take on it:
dav+fs (assumptions of current code)
* needs to generate a weak ETag for subsecond mtime unless it could
detect sub second modifications or use a mandatory lock for 1 second.
* it can't detect sub second modifications and doesn't use a mandatory
lock for 1 second.
* storing ETag will not improve your ability to generate a strong ETag
(unless you could detect the direct filesystem modifications or use a
mandatory lock).
* if you could detect the direct filesystem modifications or use a
mandatory lock then mtime+inode+length (+ modification counter) would be
enough (although this would exclude mmap modifications on unix)
* sub-second direct modifications can't be detected easily (requires
non portable interfaces like inotify) and mmap changes can probably
never be detected.
dav-only
* could generate strong ETags always if sub-second mod_dav
modifications were tracked somehow.
* mtime+inode+length (+ modification counter) would be enough (what
more is needed? no changes are happening outside mod_dav)
* probably needs to store modification/generation counter, although...
* if PUT without Content-Range was made to change the inode then most
of the common cases could probably be covered without storing anything
(although this would not cover the case where the ETag would need to
change on sub second PROPPATCH?? and PUT with Content-Range - how common
is this?).
Perhaps there is a third isolation level?:
dav+loose-fs
* only differs from dav-only in that it makes a best effort at handling
FS changes.
* could incorrectly return a strong ETag in cases where a direct file
system modification was made in the same second as a mod_dav modification
* mtime+inode+length (+ modification counter) would be enough?
* Is this any different from dav-only? Is this just an alias for dav-only?
