- From: Jason Crawford <nn683849@smallcue.com>
- Date: Tue, 4 Mar 2003 18:55:31 -0500
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "'WebDAV'" <w3c-dist-auth@w3.org>
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