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

On Tuesday, 03/04/2003 at 06:27 CET, "Julian Reschke"
<nnjulian.reschke___at___gmx.de@smallcue.com> wrote:
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> > Sent: Tuesday, March 04, 2003 6:05 PM
> > To: Julian Reschke
> > Cc: Clemm, Geoff; 'WebDAV'
> > Subject: RE: Move and Delete (was: bind draft issues)
> >
> > > > 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
>
> It may depend on the implementation and your permissions.
>
> > 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
>
> Wrong.
>
> Any directory has two hard links (it's entry in the parent, and the "."
> entry as internal member). In addition, it gets hard links for each
internal
> member that is a directory (through it's ".." entry). You can check this
> easily using ls.

Thanks.  But as far as the discussion goes, that back link to the parent
doesn't change the point of the discussion.


> > 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
>
> I'd be surprised if you could. If you delete a directory, how do you
detect
> that there are symlinks left pointing to it?

Yes, that can be difficult normally.  IMO...

If the server created the links, it can track them in a persisant database
that
it maintains.   If they were already sitting around the file system when
the
server was installed, it probably doesn't need to track those since they
weren't necessarily created as "bindings".  If probably doesn't hurt to
assume they are though when discovered.

Again... this doesn't change the main point of all this.  Atomic or not,
you need to know about all the bindings to a resource.  If you don't,
you face the same problem atomic or not.

> > 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
>
> Why do I need to fix up symlinks? It's their nature that they are weak
> links. I'd be surprised if they track another resource automatically.

You're right.  If the symbolic links were already there, then it's no
big deal to let them break since they don't really represent a
binding.

But, I'm refering to an implementation where the symbolic links
are used to implement some bindings.   Those bindings within the
deleted tree  aren't allowed to break.   So if you need to clean
up some symbolic links to make sure the interior bindings don't
break, then you must do that.


>
> > atomic, but at the WebDAV level you can block or remap access
> > until that's completed.s
>
> I may be able to block that at the WebDAV level, but the WebDAV code may
not
> be able to block other access types (such as filesystem access).

Yup.  That's right.   But if the WebDAV server has just moved it off to
it's work directory, then
it's unlikely that something else is going to interfering.  Note... we're
only trying to prevent
access to the tree via that binding.  When we did the move, we already
prevented that.
The folks that briefly won't be able to access the moved "files" are
accessing them through
symbolic links... and of course applications using symbolic links are
already aware of the possibility
of a symbolic link being broken.  And for the most part, the link will only
be broken briefly.
And... none of this is visible at the level of WebDAV.  It will look atomic
to WebDAV clients.


> > Or... you can just reject BIND requests to directories.  :-)
>
> Even if I'd do that, the current wording of the BIND draft does not allow
me
> to keep my current RFC2518-compliant DELETE implementation. I feel this
is a
> problem.

Right.  To claim BIND spec support, you have enhance the implementation to
support *this*  2518 compliant approach.... or to avoid a situations where
bind spec
violations would happen.   It's not unreasonable to expect one to have to
add code
in order to support a new feature like multiple-bindings.




------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Tuesday, 4 March 2003 18:57:02 UTC