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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 4 Mar 2003 17:34:46 -0500

From: Julian Reschke [mailto:[email-masked]]

   > From:  Clemm, Geoff
   > 
   > 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?

I am familiar with two kinds of Unix file systems wrt this issue.

The first are ones that allow you (with suitable privileges) to use
link() to create a second link (a "binding") to a directory, and that
also allow you (with suitable privileges) to use unlink() to
(atomically) remove a link (a "binding") to a directory.

The second are ones that do not allow you to use link() to create
a link to a directory, and also do not allow you to use unlink()
to remove a link to a directory (you have to use rmdir()).

In either case, it is not an instance of a repository that "supports
multiple bindings to a collection but cannot support atomic
DELETE/MOVE".

So to rephrase the question to target unix file systems, how many
examples are there of unix file systems that allow you to use link()
to create a second link to a directory, but do not allow you to use
unlink() to remove a link to a directory?  (I'm not saying there
aren't any ... just that I'm not familiar with them).

Julian: Just for interests sake, or you using link/unlink to
create bindings in your Unix file system, or something else?

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 4 Mar 2003 23:49:08 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, March 04, 2003 11:35 PM
> To: 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
> ...

No, I was just using this as an example because I thought it qualified as
example. The UFS certainly uses hard links (bindings) internally on
collections, but, as you said, it usually doesn't let people mess around
with them explicitly.

Anyway, the main issue for us is that we absolutely can not change the
DELETE collection semantics (from what we have in RFC2518), yet we *do*
support explicit BIND creation. This basically means that we can't be
compliant to the spec as it's written, and I think this is a problem. IMHO,
the spec simply should allow "both" behaviours (atomic delete with cleanup
of child resources as possible side effect), and RFC2518 semantics.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760