W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Move and Delete (was: bind draft issues)

From: Jason Crawford <nn683849@smallcue.com>
Date: Tue, 4 Mar 2003 12:05:20 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <OF6DB3F705.71C83016-ON05256CDF.0055EA95@us.ibm.com>

> > Just for interests sake, how many examples are there of
> > repositories that do support multiple bindings to a collection
> > but cannot support atomic DELETE/MOVE?
> The Unix file system?

Sort of.  On most (all?) Unix file systems you can't create a
hard link to a directory, but you can create a soft/symbolic link.
In essence, all directories have one hard link and zero or more
symbolic links to them.  The symbolic link has no referential
integrity, but that's probably not a major issue for a WebDAV
server since the link can be traversed to confirm that the referee
still exists.  (See caveat below.)

To simulate BIND support one can use symbolic links.  In that
case the action to take when doing a DELETE/UNBIND is
fairly easy if the binding is implemented as a symbolic link, but
not as easy if it's a hard link.  If breaking a hard link, there
are a number of options.  I believe you can't just delete the
subdirectory without deleting it's children.   But you can move the
directory to another location on the same file system.   It can be
moved out of the namespace or it
can be moved to replace a symbolic link to the collection.

Whether it's a symbolic link or a
hard link being removed, you still need to do a fix up of symbolic
links in to the subtree being removed.  That obviously is not
atomic, but at the WebDAV level you can block or remap access
until that's completed.

Or... you can just reject BIND requests to directories.  :-)

But more to the point of the discussion, there is nothing that will cause
the file based Unix server to need to return a status code indicating that
"part" of the DELETE/UNBIND operation occured.

Received on Tuesday, 4 March 2003 12:11:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC