RE: WebDAV Bindings - Issue Yaron.AtomicDelete

On Thu, 27 Jan 2000, Slein, Judith A wrote:
> I think maybe we haven't made it clear what we are trying to accomplish by
> saying that DELETE must be atomic.  And maybe expressing it that way is
> confusing.  Here are the results we want (I think):

In the sense that "atomic delete" meant "integrity is retained during the
delete", then mod_dav has a problem.

It appears that you are removing the word "atomic" and replacing it with
more specific language on what "delete" means. This seems fine...

> 1. DELETE removes a single binding.  It does not remove all the bindings to
> a resource, only the one identified by the Request-URI.  If it happens to be
> the last binding, then what happens about garbage collection of either
> content or properties is outside the scope of the spec.  DELETE is just
> about removing the binding.

Not a problem *if* the server does not support bindings. As long as it is
understood there can be a race condition during the processing of the
DELETE operation.

> 2. In the case where the binding is to a collection, DELETE still means only
> remove the binding to that collection.

Again, not a problem.

> It is not acceptable to walk the
> tree deleting bindings to descendents of that collection.  This would have
> disastrous consequences in an environment with multiple bindings to
> resources.

And this is the problem for both of the cases above. When bindings are
present, we've got problems. In a standard Unix file system, I can
implement bindings in one of three ways:

1) symbolic (soft) links
2) hard links
3) binding database plus custom URL translation

Note that hard links cannot operate across a "devices" and cannot be used
on directories (collections). These two restrictions pretty well obviate
(2), so we are left with (1) and (3). 

With symbolic links, there is no way to know if another resource is
referring to my "real" resource. If somebody deletes a resource and it is
just a symlink -- no problem. If the resource is an actual file or
directory, then how do I know if another resource is using it? For
scenario (1), I would have to retain a database of backpointers. If a
backpointer exists, then what do I do with the "real" resource? I must
then decide to move/rename the thing (or something).

(3) is simply a pain in the butt. It is essentially implementing a symlink
in the web server. It essentially records the backpointers mentioned in
the previous paragraph, but still doesn't solve the "what happens when the
'real' resource is deleted?"

A final option is to make *all* resources symlinks and put the actual
content somewhere else. This would require a database of reference-counts,
however. Maybe mixing with (3) to do the symlinking and refcounts might
work.

>...
> Does either of these restrictions cause problems for mod_dav?

Only in the presence of bindings. There would be a LOT of work to
correctly handle bindings and deletes.

To make it more easily implementable, I would need one of two items:

1) binding between collections is not allowed (this would allow hard
   links; I could live with the device restriction)

2) it is allowable to leave dangling references (a symlink to a "real"
   resource that has been deleted)


Neither of these are very appealing. As it stands, it appears that the
binding specification *requires* a database that maps URLs to resources
(outside of a standard web server's URL translation system).

If a database was required, then I simply wouldn't implement bindings all
that soon. But it *would* be possible.

[ I'm not suggesting that we punt/restrict features such as binding simply
  because particular filesystems cannot support the feature in question;
  I'm just saying that it will take longer to code... ]

The impossible part is guaranteeing that no race conditions exist during
the processing of the DELETE.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 27 January 2000 21:27:31 UTC